Hi, I'm getting an HDL ADVISOR message when I synthesize this code. Basically, it is a big shift register that shift-in data on each rising edge of mclk if srclkRise is high, and outputs its data on the rising edge of mclk if lrclkRise is high. I don't quite understand the advice here. Can anybody help? Thanks, David
--ADVICE INFO:Xst:741 - HDL ADVISOR - A 9-bit shift register was found for signal and currently occupies 9 logic cells (5 slices). Removing the set/reset logic would take advantage of SRL16 (and derived) primitives and reduce this to 1 logic cells (1 slices). Evaluate if the set/reset can be removed for this simple shift register. The majority of simple pipeline structures do not need to be set/reset operationally.
--CODE always @ (posedge mclk or negedge resetb) begin if (~resetb) begin datain
"David" schreef in bericht news: snipped-for-privacy@posting.google.com...
I think it's the resetting code at the beginning that causes this. Resetting all the registers is set/reset functionality. I don't know Verilog that well, but it seems this is a synchronous reset; that means that for each register a 2:1 mux is needed, one input to load a zero, and the other input to load the data from the neighbouring register. Converting this to an asychronous reset would remove all those muxes, and utilize the dedicated preset/reset input on the flipflop.
The SRL16 does not have a reset pin on it...ie, you can't clear its contents in one clock cycle. Your code has a reset in it that clears the whole shift register, which means it cannot be implemented using an SRL16 primitive (which costs only one LUT+FF instead of 9). If you can eliminate the reset on this shift register, then you get a more compact implementation. Your code would look like this:
always @ (posedge mclk or negedge resetb) begin if (sclkRise == 1) begin datain[63:1] advice here. Can anybody help?
--
--Ray Andraka, P.E. President, the Andraka Consulting Group, Inc.
Ok I understand...but isn't it better to have a reset for all our flip flop? If something goes wrong - or when I press the reset button...- the controller can always reset everything to zero before we start again...
"Better" is an interesting word. Sure, it's cleaner. How much are you willing to pay for that? If it's just data in a pipeline things will get cleaned out after a few cycles. (May not be true if IIR filters are involved.)
Note for example that (most) RAMs don't have a reset pin to clear out the whole array.
--
The suespammers.org mail server is located in California. So are all my
other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited
commercial e-mail to my suespammers.org address or any of my other addresses.
These are my opinions, not necessarily my employer's. I hate spam.
Depends on your design and what you are willing to settle for. Technically speaking, all you really need to do is provide a way of clearing stuff in your design tht is inside hardware loops. For example, a state machine or an IIR filter have a 'loop' that needs to be broken in order to bring the hardware to a known state. In many cases, it is perfectly acceptable to clear only key points in the design, and sometimes even require the reset be asserted for some minimum number of clock cycles to achieve a known state. Yes, the easy methodology is to reset every flip-flop, but it is not necessary and can cost you dearly in terms of both gates and reset signal fan out (and therefore delay).
Dave wrote:
--
--Ray Andraka, P.E. President, the Andraka Consulting Group, Inc.
If something goes wrong - or when you press the reset button...- would you be willing to wait for the FPGA to reprogram itself? If you design the system to boot the FPGA from a PROM or reprogram it from the processor, the "clean" state would be guaranteed after the system reset and would allow proper "initialization" or SRL and BlockRAM contents. The async resets are more a leftover from ASIC designs than a sincere need for FPGAs.
I believe it is important for testing purposes that a known state be reached with a known combination of reset, clocks, and other signals.
It might be that a design would work perfectly well in any of the possible reset states, but it wouldn't be testable.
Well, that is mostly for ASICs where test vectors need to be supplied to the fab. For FPGAs it might not be necessary, though test vector sets are nice to have.
But Glen, you can get the whole circuit to a known state by just using strategically placed resets. Take a simple example of a pipeline that has an accumulator in it. All that needs to be reset is the registers at the pipeline input (these should be held at a know value for some known number of clocks), and a reset on the accumulator, which is needed to clear out the history stored in the accumulator (it won't self clear regardless of the data coming in because of the feedback loop). If your pipeline is say 10 clocks long, then holding the reset to the input registers and accumulator for 10 clock cycles will get the entire circuit to a known state without having to reset every flip-flop. You can take it a step further by also resetting the output register and using some delays for the resets so that the operation as viewed from outside is indistinguishable from a synchronous reset. In that case, the input register is cleared as long as reset is held. The reset signal is delayed in a shift register matching the length of the pipeline and tapped where needed to break loops, and the reset for the output register is handled with a set-reset flip-flop that is set by the reset input and reset by the delayed reset as the first valid input after the reset is released reaches the pipeline output.
My point is that you do not have to reset every single flip-flop in the design to reach a known state as long as you are willing to take a known number of clock cycles to reach that state.
glen herrmannsfeldt wrote:
--
--Ray Andraka, P.E. President, the Andraka Consulting Group, Inc.
Yes. That is included in what I wrote as a known combination of reset and clocks.
It gets more complicated if you have memory elements other than pipelines, such as registers in a CPU. While the processor might work just fine with them in a random initial state, testing might not. All these things have to be considered at design time. It might be that they don't add much logic, but they do add to the time it takes to verify the design.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.