New answers tagged

0

Unfortunately Icarus doesn’t seem to have an up-to-date synthesis flow, which you would need to visualize your RTL as logic. You could try the free online evaluation versions of Xilinx Vivado. This will extract a post-synthesis schematic showing how compilation and synthesis rendered your RTL into internal logic elements (LUTs, flip-flops, i/o blocks, etc.) ...


1

What you need is a FIFO with different input and output bit widths. This can be achieved with an array using two index pointers and a register keeping track of the numbers stored bits. The pointers will wrap around. The bit with of the stored bits need to be a common multiple of the input and output widths. Here is some SystemVerilog code to get you started....


2

FPGAs have hardware multipliers on them these days (for example, the DSP48 MAC block in Xilinx architectures.) That said, it probably depends on the size of the MPY. Back when I was working on this stuff (1980s, at Weitek) modified Booth's algorithm was all the rage for 16, 32 and 64-bit sizes. Now? Not sure. Since then there's the Carry-save architecture ...


1

I strongly suggest you try 8'bzzzzzzzz; as you vector is 8 bits wide, not 1 bit.


0

This is not a ring oscillator, because r0 is unknown. You probably meant r_out: and a(n6,r_out,start); Also see: rout vs r_out. If you correct your topology, you will run into another problem: a timing (delta) loop, basically a correct ring oscillator without delays will hang your simulator at 0 time. You will have to introduce a delay in your "mynot" ...


0

You can use several approaches to generate permutations, e.g. follow this link. Using the above, the easiest is that you explicitly generate the instantiations for each permutation e.g. in Java (all 120 instantiations, exactly as you show in your example), write it into an include file, and in your program you just `include that file. Problem solved, no ...


0

Just as Hacktastical said, the synthesis will implement this with 136 small muxes. What I'd like to add is the issue may be about the 'sl' signal which will connect with 136 muxes. If the muxes are far from each other physically, it may be difficult for 'sl' signal to meet the timing requirements of each mux connected. If there is timing violation, you can ...


0

It really doesn't matter how you write the code, it will be synthesized to the same thing. A 136 bit 2:1 mux is really not that bad. It's really the number of inputs that really dictates the complexity and causes timing issues, not so much the width, though that does place a large fanout on the select signal. If that was a 2 bit 136:1 mux, then maybe you ...


0

One way to avoid the timing problems of a big wide mux is to pipeline the selection if that meets your latency requirements.


2

I don't think it matters. Synthesis will smash this down to 136 2:1 muxes regardless of how you describe them in HDL. That's not that much in the larger scheme of things if you're building something with that large of a datapath (128 data, 8 enables, right?) Insert register slices if it needs help to close timing.


0

With Vivado you can do this one of four ways: Define the counter with HDL (uses fabric and LUTs) Instance a DSP48 with HDL Use block design Binary Counter, instance as 'fabric' Use block design Binary Counter, instance as 'DSP48' You can also define your own parameterized RTL blocks if you need something more exotic than that.


0

del1 and del1 are defined as reg which is only 1-bit. Try defining them as reg [7:0]. Also fold in Oldfart's and Elliot's suggestion of fixing blocking (=) / non-blocking (<=) assignments. Combinational logic (eg: always @*) should use blocking (=). Sequentail logic (eg: always @(posesge clk)) should use non-blocking (<=)


0

Verilator has limits on the size of arrays it will dump. See these two switches: --trace-max-array <depth> Maximum bit width for tracing --trace-max-width <width> Maximum array depth for tracing


1

My guess is it requires more than one clock to calculate ((l_count * 68) / 100000) + 1. There should be a warning about this in the synthesis/timing report. First thing that can be done is reduce the 68/100000 to 17/25000. The synthesizer should have done the same optimization. Then split the calculation across multiple clocks. Notice in the CatchEchoState ...


0

A signal should not exists on the left and right side of an assign statement. A latch should be assigned in it own always @* block (with SystemVerilog use always_latch) and use non-blocking assignments (<=). When all possible inputs combinations are described in an always @* then the block describes combinational logic. If it is not fully described then ...


0

"Read only" registers are generally used to get data into the CPU that's coming from somewhere else, such as status information from a peripheral interface. Such a register requires additional input port(s) to bring that data in from one or more other modules. That data may or may not need to be resynchronized to the CPU clock for correct operation.


1

To read its content at the given address... I suspect your code has been reduced a bit too much, it is not looking at all like a CPU interface. This might be a school assignment so I only provide an outline of the code. (Which, by the way, has not been syntax checked) ... input [7:0] read_only; ... reg [7:0] write_only; reg [7:0] read_write; always @(...


Top 50 recent answers are included