RTL 10 Commandments

[Mike Treseler]

Beanut wrote:

11. Do not mix behavioural and structural in a single block.
Mixing them requires a synthesis run on the higher hierarchical
levels, and may take obscene amount of runtime. When the block is
fully structural, the subblocks may simply be linked together.

I think this is a venial sin not requiring a commandment.
Sometimes I have to compose my_improved_entity using
my_entity + another_entity + process:glue
and I like to see the new glue code and the old
instances all in the same architecture.

I am an advocate of having a global reset and many still recommend it:
http://www.chipdesignmag.com/fpgadeveloper/august2005.html
I do not buy into the routing issue because I treat the reset as a high
fanout net. In an ASIC I would route it as a clock, in an FPGA I
connect it to one of the prerouted clocks. Does anyone else advocate
removing global reset?

Not me. It is an advantage
for simulation and vendor independence
and costs nothing for an FPGA target.
Note that large structures can power up
in one state and synchronously init
to another during an idle state.

Will someone provide some insight into the problem with synchronizing a
bus? I was intending commandment 4 for control signals, but I've never
had a bus problem.

Works fine for controls.
Can work fine for serial data too.
Parallel data is the problem.
Say the clock hits just as the asynch count
is rolling over from x"FFFFFFFF" to zero.

-- Mike Treseler

 

[Kai Harrekilde-Petersen]

Martin Thompson <martin.j.thompson@trw.com> writes:

Kai Harrekilde-Petersen <khp@harrekilde.dk> writes:

Martin Thompson <martin.j.thompson@trw.com> writes:
"Beanut" <fourbeans@gmail.com> writes:
snip
2. Always reset signals.

Not always. Only when it matters, especially in FPGAs, as otherwise
you'll have to route that signal around to places that don't really
need it. See

http://www.xilinx.com/xlnx/xweb/xil_tx_display.jsp?sGlobalNavPick=&sSecondaryNavPick=&category=&iLanguageID=1&multPartNum=1&sTechX_ID=kc_smart_reset

But for an ASIC, I think this is very good advice. Take a flop without
a reset, add a bit of gate-level simulation, and hey presto! you've
got X'es all over the place.


True - not an ASIC man myself - surely there are ways of dealing with
unreset flops in simulation, they are "don't cares" after all?

The problem is really two-fold:

1) If you have 'X' on just about any port on a gate or flop, it will
tend to emit X on the output(s) as well. Closed loops (e.g. divide-
by-2 for clocks), will keep the X'es going forever. You need to force
the output or state of particular flops to get rid of this problem.

2) Identifying the points where you need a 'force' to quelch the X'es
is a manual task - it takes time. Also, for paranoia reason, we prefer
to have a 'clean' gate-level simulation, where we only manipulate the
pins on the device, rather than relying on setting internal point of
the chip, to get it working.

If you rely on setting the internal state once too many, boom - you
need to do a respin, which will cost you real $$$ and another 3+
months.

Assessing which flops that *could* live without getting reset is a
much bigger task that just saying 'all flops must be reset', and
enforcing that rule (the backend guys have scripts for checking it).

Yes, you could live without it, but the cost of doing it vs the
benefit gained tells me to do it. It's just another problem solved, so
I can spend my time at more productive stuff.

We've used this rule at work since 2000, when we started. We have a
long list of tapeouts - and almost all of them has been able to go
into full production without touching a single metal layer.

Being able to get first silicon to full production is a huge plus -
you're not getting bogged down trying to fix the bugs, and secondly
you are able to work on the next products - productivity soars, and
you're leapfrogging the competitors who are spinning their old chips
again and again.

Cheers,


Kai
--
Kai Harrekilde-Petersen <khp(at)harrekilde(dot)dk>

 

[Mike Treseler]

Martin Thompson wrote:

Don;t
you just wait for the data in the data path to ripple through and
things to become valid

It depends on the design.
However completing a regression suite
takes long enough as it is and this
is an optional problem.

The OP wants guidelines for beginners
and hooking up a global reset is free
and easy for FPGAs.

-- Mike Treseler

 

[Jeremy Stringer]

Beanut wrote:

I am an advocate of having a global reset and many still recommend it:
http://www.chipdesignmag.com/fpgadeveloper/august2005.html
I do not buy into the routing issue because I treat the reset as a high
fanout net. In an ASIC I would route it as a clock, in an FPGA I
connect it to one of the prerouted clocks. Does anyone else advocate
removing global reset?

One point is that if you route that reset over global clock routing,
then you've lost one global clock buffer - these things are in short
supply in some designs That said, for a beginner, it's probably the
easiest option.

Also - it's not RTL level per se, but applies to actually applying it in
a design - "Thou shalt design thy clocking mechanisms". Ie make sure
that you have enough global clock buffers, DCMs/PLLs etc, and that they
are connected in a manner which makes sense. (IE not trying to run a
DCM with a feedback on the other side of the chip running through local
routing).

My 2c,
Jeremy

 

[David Brooks]

Kai Harrekilde-Petersen wrote:

"Beanut" <fourbeans@gmail.com> writes:
[snip]
9. Implement state machines with one of the following implementations:
a. 3 process state machine.
One synchronous process for updating state with next_state
One state machine process updating next_state only
One state machine process updating outputs only
b. 2 process state machine (preferred method)
One synchronous process for updating state with next_state
One state machine process updating next_state and outputs


Actually, I don't see the value of this rule. But I'm not a beginner
anymore, so I know where I can cut corners and still avoid getting
burned

The point here is to make sure your synthesis tool understands you.

Synthesisers are not magic: they work by comparing your code with a
series of canned templates to identify your intentions. Any worthwhile
synth. can understand the 2- and 3-process models. If however, you write
your own baroque state machine, its open season.

 

[Zara]

On 26 Oct 2005 10:10:32 -0700, "Andy Peters" <Bassman59a@yahoo.com>
wrote:

Beanut wrote:

9. Implement state machines with one of the following implementations:
a. 3 process state machine.
One synchronous process for updating state with next_state
One state machine process updating next_state only
One state machine process updating outputs only
b. 2 process state machine (preferred method)
One synchronous process for updating state with next_state
One state machine process updating next_state and outputs

Well, include me in the list of people who prefer the single-process
state machine.

-a

Include me too.

 

[Mike Treseler]

David Brooks wrote:

The point here is to make sure your synthesis tool understands you.
Synthesisers are not magic: they work by comparing your code with a
series of canned templates to identify your intentions.

It isn't magic, but it does produce
an netlist that sims the same as my baroque code.
It even draws a schematic for me.
That's a pretty good trick.

-- Mike Treseler

 

[Martin Thompson]

Kai Harrekilde-Petersen <khp@harrekilde.dk> writes:

Martin Thompson <martin.j.thompson@trw.com> writes:
"Beanut" <fourbeans@gmail.com> writes:
snip
2. Always reset signals.

Not always. Only when it matters, especially in FPGAs, as otherwise
you'll have to route that signal around to places that don't really
need it. See

http://www.xilinx.com/xlnx/xweb/xil_tx_display.jsp?sGlobalNavPick=&sSecondaryNavPick=&category=&iLanguageID=1&multPartNum=1&sTechX_ID=kc_smart_reset

But for an ASIC, I think this is very good advice. Take a flop without
a reset, add a bit of gate-level simulation, and hey presto! you've
got X'es all over the place.

True - not an ASIC man myself - surely there are ways of dealing with
unreset flops in simulation, they are "don't cares" after all? Don;t
you just wait for the data in the data path to ripple through and
things to become valid (thinking of a FIR filter for example). If you
have a feedback path that matters, then you need to control that
correctly, but that still doesn't mean you *have* to reset all the
forward flops does it?
<snip>

Cheers,
Martin

--
martin.j.thompson@trw.com
TRW Conekt - Consultancy in Engineering, Knowledge and Technology
http://www.trw.com/conekt

 

[Harpreet]

Hi,
I am a novice in VHDL. I wish to know that when you say only
derivatives of a clock is used, can I generate another clock for
parallel to serial conversion.
For example, if the MASTER_CLK delivers input at 1 sample(8 bits) per
40 microseconds, can I generate a SLAVE_CLK which can process the rest
of the circuit (implying every bit) at 5 microseconds (in effect, 5
microseconds per bit).
regards,
-Harpreet

p.s. - the context relates to serial distributed arithemtic
implementation of fir decimation filter.

 

[Beanut]

What I was referring to was a divided down clock which is really just a
counter running off the global clock and you pull off the bit that is
of interest. It has some additional delay from the global clock to
tack into consideration during static timing analysis, but it will be
synchronized so you do have to worry about the rules for asynchronous
signals.

In your example the 5us clock should be the primary clock and you
should clock in the parallel word every 8 clocks. I would recommend
AGAINST creating two clocks. Just register your data bus based off a
3-bit counter. This keeps you at a single clock and all you logic
running at the faster (fast is relative here) speed.

Enjoy!