GitLab

Merge branch 'merge-staging-2019' of https://github.com/casper-astro/mlib_devel into merge-staging-2019

Issue 96

Don't pointlessly return compile command

Fix issue #46

Give the software register (FPGA -> CPU) one simulation output
for each of the input signals.
Because I'm lazy, and don't want to mess around with slicing/dicing/casting
the output, just hook up simulation gateways directly to the block inputs.
Match the latency of the real pipeline, and assume (optimistically?) that the
compiler will be smart enough to optimize away the non-HDL gateways

Address Issue #84

Make the default value of hardcoded shift schedule [] on the fft block.

Otherwise, even if hardcoded shift schedule is not selected, the design_info
scraper will fail with a "no value found"

Snap1 fixes

Requirements

This is md, not rst!

Add many more platforms, and include requirements.txt install commands

I have added sys_block version defaults. They now get populated to the XML. The sys_block version registers are still not properly connected in top.v, so read back zero. I suspect some python code needs to be populated still. I have fixed the Red Pitaya timing constraints as the clock names have changed to DSP clock from the original user_clk.

Not sure whether or not LD_PRELOAD should be in startsg. Seems like it should
be optional because it may well be OS / version dependent

The code now uses an installed version

This might one day make for a cleaner message if something goes wrong and
this script isn't being called directly (i.e. isn't sys.argv[0])

This prevents other instances of argparse elsewhere (in xml2vhdl)
from trying to process these flags

Added support for these clocks in the red pitaya

I now refer to the clock source pins instead of the clock name and this allows Vivado to identify the clocks during synthesis. Hence, there are no critical warnings.

This contains the AXI memory mapping fix that sorts out the issue with
multiple snapshots and brams, plus naming conventions.

Had an issue where, if there were (eg) three 4-byte registers
on the sw_reg device bus, the xml2vhdl code would generate
a device with `byte_size="8"`.
Traced this to an (I think) erroneous calculation of size in
the xml2vhdl package.

This commit also tweaks the verilog.py source so that sw_reg
is not always placed last, but is placed in accordance with its size.
This fixes my misunderstanding -- the top-level devices need to be
N-byte aligned, not the underlying (32-bit) registers. Therefore
we can't assume that the sw_reg block should go last. It may be
relatively large.

Also round up memory spaces to 2**n bytes before ordering. This
shouldn't change anything, but means the calculation done by the toolflow
and xml2vhdl should match.

The reinterpret and cast in the ADC yellow block has been removed. This has been tested and still works.

This should mean it is automatically aligned appropriately

To try and comply with an xml2vhdl requirement that an
N-byte device be aligned on an N-byte boundary.
If all devices are 2^m bytes, this should work.

It's unclear to me whether the alignment needs to be
at the axi device level, or the sub-register level.
If the former, then I don't think this will fix having (eg)
random numbers of registers, since the total size of the sw_reg
space will not be a power of 2 bytes (even though each register
within the space is 2^2 = 4 bytes in size)

Merge branch 'merge-staging-2019' of https://github.com/casper-astro/mlib_devel into merge-staging-2019

Post merge 1gbe fixes

Don't print top.v to screen.
Remove some debugging parameter prints from verilog.py

Didn't check for functionality.

Needs "generate top module" set on export, otherwise
sourcing the tcl doesn't generate the block diagram.