I hate VHDL!!!

[Hank]

"ALuPin" <ALuPin@web.de> wrote in message
news:b8a9a7b0.0407120157.6cf038c1@posting.google.com...

Hi,

does someone know links to FPGA/CPLD related sites about
VHDL design of VGA controller, hsync, vsync, composite sync in general ?

I would appreciate your help.

Kind regards

The xilinx spartan 3 starter kit documentation has quite a bit of info on vga
signals and there is a vhdl file you can download here that has a vga character
mapped controller (the microblaze package):

http://www.xilinx.com/products/spartan3/s3boards.htm

 

[Jeroen]

"ALuPin" <ALuPin@web.de> wrote in message
news:b8a9a7b0.0407120157.6cf038c1@posting.google.com...

Hi,

does someone know links to FPGA/CPLD related sites about
VHDL design of VGA controller, hsync, vsync, composite sync in general ?

I would appreciate your help.

Kind regards

try http://www.fpga.nl/index.html?lancelot.html which is a working VGA
implementation for an Altera Cyclone, have seen it working

 

[DrB]

Phil

Thank you for the dits

If only one could RTFM (Read The Full Manual) - it never seems to get
published these days

An F* problem in its own right; but fore warned is fore armed

Martin


"Phil Hays" <Spampostmaster@comcast.net> wrote in message
news:av25f0psef0joqr911kraedr7rbdco8q4d@4ax.com...

On Mon, 12 Jul 2004 10:26:21 +0100, "DrB" <nospam@nospam.no> wrote:

There is another common issue with DCMs or DLLs that you might also be
having a problem with. Are you using a DCM or a DLL?

Your allusion to "common" DCM / DLL issues has aroused my curiosity.

Sure. I'm not sure "common" was the correct word, but I suspected
that the original poster might have run into the following issue.
I've seen it in someone else's design. These problems are curable by
reading the fine manual (RTFM).

RTFM # 1 "Do not use the DCM output clock signals until after
activation of the LOCKED signal. Prior to the activation of the LOCKED
signal, the DCM output clocks are not valid and can exhibit glitches,
spikes, or other spurious movement."

You can keep the part in configuration until the DCMs are locked by a
bitgen option, or you can use the synchronized locked signal to force
reset to all state machines and all other critical logic. Better do
one of the two. The bitgen option is probably best, unless you may be
resetting the DCMs after configuration, in which case you need to do
the second.


I didn't think he had this issue, but I've seen it as well. In my own
design.

RTFM # 2 "To ensure consistent locking, if a DCM is configured with
external feedback, applying a reset after configuration is strongly
recommended."

"Strongly recommended" isn't quite correct. "Required" would be
better wording.


--
Phil Hays
Phil-hays at posting domain should work for email

 

[Mike Treseler]

Gopi wrote:

Hello Everyone,
I am doing some programing in VHDL. I want to write a VHDL program
that accept ethernet frame and convert it to PPP frame (point to
point

Did you happen to read the replies
when you asked this question
a month ago?

http://groups.google.com/groups?q=vhdl+ethernet+ppp+gopi

-- Mike Treseler

 

[Jerker Hammarberg (DST)]

I have now implemented the protection against race condition as a result of
asynchronous reset, as proposed by Phil and others. The machine hasn't
locked after that, so hopefully that was the solution.

I learnt a lot through this discussion. Thanks a lot to all who contributed!

/Jerker

 

[Peter Alfke]

A Xilinx App Note was suggested. Here is an attempt.
Let me know if it makes sense.

Beware of Start-Up Synchronization Errors
Peter Alfke, July 12, 2004

All Xilinx FPGAs provide global (p)reset to all internal flip-flops and
latches, which means that every flip-flop is either set or cleared
(configuration option) when the FPGA goes active after configuration has
been completed. This attractive feature requires no general routing
resources. It is łfor free˛, but like with many łfree˛ offers, there can be
strange side effects.

€ The (p)reset signal is distributed across the whole chip, and it is not
very fast. Tens of nanoseconds delay are common on large chips.
€ The (p)reset signal is synchronous with either CCLK or, better, with the
user clock, but there may be more than one user clock.
€ The user clock is normally running while the FPGA is being configured.
This is only tolerable because flip-flops are being held (p)reset, nodes are
forced High, and outputs are being held inactive, as described in the
configuration documentation.

These three features combined can cause unreliable start-up after
configuration, when the trailing edge of the asynchronous (p)reset signal
has so much skew or uncertainty with respect to any flip-flop clock, that
some flip-flops can begin operating on different clock cycles. This might
lead to an irrelevant start-up glitch, but it might also cause a state
machine to enter an illegal state, or even to freeze up.

There are several alternate solutions to this problem.

1.
Disable all clocking until about 100 ns after the end of GSR, the automatic
global signal that asynchronously (p)resets all flip-flops.

2.
Distribute a synchronous CE (clock disable) signal with a tight distribution
delay of less than one clock period.

3.
Analyze the design for sensitive circuitry, e.g. state machines, and create
a localized synchronous CE signal that delays operation for several clock
cycles after the end of GSR.

A convenient reset synchronizer and stretcher consists of a flip-flop with
the usual GSR reset, with a High on its D input, and with its Q output
driving the SRL16 input to its own LUT. The SRL16 output then goes High a
controlled number of clock pulses after the end of GSR. This is a good
signal to use for driving the CE input of critical state machines.

Ken Chapman published a longer and more entertaining description in
TechXclusives.
Click on this insanely long URL:

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


Peter Alfke

From: "Jerker Hammarberg \(DST\)" <jerkerNO@SPAMdst.se
Organization: DST Control AB
Newsgroups: comp.arch.fpga,comp.lang.vhdl
Date: Tue, 13 Jul 2004 18:14:14 +0200
Subject: Re: FSM in illegal state (conclusion)

I have now implemented the protection against race condition as a result of
asynchronous reset, as proposed by Phil and others. The machine hasn't
locked after that, so hopefully that was the solution.

I learnt a lot through this discussion. Thanks a lot to all who contributed!

/Jerker

 

[Jim Lewis]

Hal,

What do ASIC/CPU designers do? My guess is that they don't
have a global-reset so their version of this problem is a bit
different.
In ASIC design, we would connect the asynchronous reset to the

circuit Ken showed (or one like it). Reset for each clock
domain is separately synchronized. Reset would need to settle
in a clock period. Routing generally allows this. If not,
you work it out (build a fanout tree with buffers or
registers). Going back some time, on my first ASIC we had
to manually balance the clock tree.

See my post. GSR would be generally alot more useful if
we could quantify in general that it settles in X to Y
amount of time and then apply its output to a circuit like
the one Ken shows to stabilize all logic or all control
logic. From the difference between Y and X we could calculate
how many states we needed to delay "critical" reset so that
it occurs last. Four registers is kind of ad-hoc and means
something much different for different clocks (20 MHZ vs
200MHZ).

Of course, going a step further, since synthesis tools can
and do recognize statemachines, and they know the clock
frequency of a particular clock, they could automatically
do the right thing for Xilinx (insert Ken's circuit).
However I like being in control of these type of things
and I am not sure I would like this solution.


Cheers,
Jim
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Jim Lewis
Director of Training mailto:Jim@SynthWorks.com
SynthWorks Design Inc. http://www.SynthWorks.com
1-503-590-4787

Expert VHDL Training for Hardware Design and Verification
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

 

[rickman]

Jim Lewis wrote:

Peter,
Since the Xilinx parts have internal POR, it seems a
shame not to use it. However, since GSR is slow, we
are cautioned against using it due to problems like
these.

I don't think the problem with GSR synchronization equals a
recommendation to not use the GSR. The point is to use it with
"caution" and to take the appropiate design steps.

Is there a way to connect the output of GSR to the
input of the circuit that Ken Chapman suggested in
the section "Strategy for the 0.01% of cases" of his
TechXclusive and leave off the asynchronous reset input.
Would this be a way that I can effectively cause all of
resets (or critical resets) for a clock domain to be
deasserted at the same time without having to
have a redundant external POR?

Reread Peter's post. It is a good start and I think you misunderstood
some of the points in it. You don't need an external reset and most
likely you don't need a sync reset that is "global" to a clock domain.
Typically there are subsets of the design which are sensitive to
synchronous release of GSR. These circuits are typically FSM, counters
and the like. Normally the data path does not care about reset since it
will immediately go to the correct state on the next clock.

One circuit you can add to any FSM to provide a sync reset is just one
or a pair of FFs which work just like a metastability reduction
circuit. Have the GSR hold these FFs in the '1' state and wire the D
input of the first one to a '0'. The last output will be your sync
reset. The sync reset will be held for one or two clock edges after the
release of GSR. This will only need to be used by the first two bits of
a one-hot FSM, the first changed bit of a gray coded counter, the first
bit of a JRC or even the first bit of a binary counter (assuming it
starts at 0); and so will not overly complicate them and slow them
down.

I have done lots of FPGA designs and have never needed anything complex
to start the chip up. Just pay attention to the startup and don't
assume that all FFs are released at the same time, between FSMs, not
just within them.

If this is possible, is there a VHDL coding methodology
that you can recommend? The big missing piece for me
is how do I access the output of GSR?

This is something that should be added to Peter's app note.

#1: Explicitly through instantiation?
#2: Implicitly through initializing the VHDL
signals that create the registers?
Although this technique seems possible in XST,
would it also work the same in other synthesis tools?
#3: Put the reset logic in a separate hierarchical
block and explicitly code an asynchronous reset, but
at the next level of the design tie the asynchronous
reset to a constant inactive value?

You don't need to access the GSR signal explicitly. If you provide an
async reset control that is common to most/all of your sequential logic,
I believe the tools will infer the GSR.

run_en_reg: PROCESS (sysclk, reset) BEGIN
IF (reset = '1') THEN
run_en <= '0';
ELSIF (rising_edge(sysclk)) then
run_en <= '1';
END IF;
END PROCESS;

This is what I use. But I only refer to the run_en signal in the FFs
that actually need to be released synchronously.

If I have multiple FPGAs and they are all connected
in a serial fashion for configuration, is the internal
POR released at approximately the same time?

Approximate is the key word. There is a common sync signal to provide
this, but you still have the wide range of delay inside each chip and
you need to select what clock is used to control it.

The details of POR and GSR functionality has always been a
little troubling to me, is there a good (really detailed)
application note that you can recommend.

You can learn a lot about it by reading how the end of configuration
works. But the main thing is to stop assuming that the end of GSR is a
synchronous event. On other chips we get used to the reset just working
(like magic). In the FPGA we need to give it a little thought, even if
it is not really hard.

--

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design URL http://www.arius.com
4 King Ave 301-682-7772 Voice
Frederick, MD 21701-3110 301-682-7666 FAX

 

[Peter Alfke]

Let me get back to the fundamental problem:
We distribute a (p)reset signal all over the chip. The problem is not the
activating edge of this signal, it's the release of (p)reset. No matter how
we distribute and phase it (unless there is only a single user clock of
relatively low frequency) the trailing edge will not appear at every
flip-flop in the same clock period. Whether the (p)reset is asynchronous or
synchronous does not matter. I do not see a way to solve this dilemma on the
chip-hardware-design level.
I suppose the software could be made smart enought to handle this, same as
smart designers can design around this. Especially with an elegant construct
like SRL16.
Peter Alfke

From: Jim Lewis <Jim@SynthWorks.com
Organization: Posted via Supernews, http://www.supernews.com
Newsgroups: comp.arch.fpga,comp.lang.vhdl
Date: Wed, 14 Jul 2004 12:01:13 -0700
Subject: Re: FSM in illegal state (conclusion)

Rick,
These circuits are typically FSM, counters and the like.
Normally the data path does not care about reset since it
will immediately go to the correct state on the next clock.
I am a former ASIC designer. I think I understand this
part well. I do have a couple concerns. First I want a
reset methodology that is device independent and
simulates well for any ASIC or FPGA technology not
just specific to Xilinx. Hence, everything that requires
reset will need the synchronized reset. I agree most
data path does not need reset (except for on some ASIC designs
to get the device to pass vectors more easily on the tester).

My second concern is that selective reset is not for
everyone. For some this methodology will cause chaos.
For a design review with selective reset, this is just
one more item that needs to be reviewed in detail.


One circuit you can add to any FSM to provide a sync reset is just one
or a pair of FFs which work just like a metastability reduction
circuit. Have the GSR hold these FFs in the '1' state and wire the D
input of the first one to a '0'. The last output will be your sync
reset. The sync reset will be held for one or two clock edges after the
release of GSR. This will only need to be used by the first two bits of
a one-hot FSM, the first changed bit of a gray coded counter, the first
bit of a JRC or even the first bit of a binary counter (assuming it
starts at 0); and so will not overly complicate them and slow them
down.
To me this seems like Chaos**n. Not that it will not work,
it just adds more details you need to manage.

This methodology would have to buy me something significant
(speed or device size) for me to want to do additional
analysis and verification to prove that a circuit designed
as above actually works under all conditions.


If this is possible, is there a VHDL coding methodology
that you can recommend? The big missing piece for me
is how do I access the output of GSR?


This is something that should be added to Peter's app note.


#1: Explicitly through instantiation?
#2: Implicitly through initializing the VHDL
signals that create the registers?
Although this technique seems possible in XST,
would it also work the same in other synthesis tools?
#3: Put the reset logic in a separate hierarchical
block and explicitly code an asynchronous reset, but
at the next level of the design tie the asynchronous
reset to a constant inactive value?


You don't need to access the GSR signal explicitly. If you provide an
async reset control that is common to most/all of your sequential logic,
I believe the tools will infer the GSR.

run_en_reg: PROCESS (sysclk, reset) BEGIN
IF (reset = '1') THEN
run_en <= '0';
ELSIF (rising_edge(sysclk)) then
run_en <= '1';
END IF;
END PROCESS;

This sounds like it would address my needs nicely.
What do you connect reset to? Do you just leave
it floating? What do you do with it in simulation?

If there is something here that would work with
XST, Synplicity, and Mentor, without changing the
code, this would make me happy. Especially if
the only thing I needed to change for each FPGA/ASIC
technology is the reset block and where the power-on
reset comes from.


You can learn a lot about it by reading how the end of configuration
works. But the main thing is to stop assuming that the end of GSR is a
synchronous event. On other chips we get used to the reset just working
(like magic). In the FPGA we need to give it a little thought, even if
it is not really hard.
On ASICs reset is explicit. On your flow above with Xilinx,
I code reset on the register, hook it to ?? or leave it
unconnected, and then "magically" it gets connected to GSR.

Is there a datasheet, manual, or appnote you recommend reading
on configuration.

Cheers,
Jim
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Jim Lewis
Director of Training mailto:Jim@SynthWorks.com
SynthWorks Design Inc. http://www.SynthWorks.com
1-503-590-4787

Expert VHDL Training for Hardware Design and Verification
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

 

[rickman]

Jim Lewis wrote:

Rick,
These circuits are typically FSM, counters and the like.
Normally the data path does not care about reset since it
will immediately go to the correct state on the next clock.
I am a former ASIC designer. I think I understand this
part well. I do have a couple concerns. First I want a
reset methodology that is device independent and
simulates well for any ASIC or FPGA technology not
just specific to Xilinx. Hence, everything that requires
reset will need the synchronized reset. I agree most
data path does not need reset (except for on some ASIC designs
to get the device to pass vectors more easily on the tester).

My second concern is that selective reset is not for
everyone. For some this methodology will cause chaos.
For a design review with selective reset, this is just
one more item that needs to be reviewed in detail.

I don't design huge devices. I also normally need to conserve gates.
So I typically am working close to the hardware. This selective reset
(as you call it) is just SOP for me. I don't use test vectors (can't
you provide don't cares?) and the chaos is only if you don't use it
correctly.

But all of this is only to save gates and/or improve speed. Trying to
route a chip wide sync reset can end up running into the same timing
issues as the async reset if the fanout is too large. I once worked on
an Altera design where we had CEs with large fanouts at 80 MHz. The
timing analysis software did not work correctly for these signals and we
had a he77 of a time getting the chip to actually work on the bench when
the software said all was well. Being 80% full didn't help much
either. But my point is that chip wide, large fanout signals can be
problematic. So I make sure I understand what my chip needs to startup
correctly and deal with that. Of course ASIC design requires a whole
different level of confidence, but the method is not any different for
an ASIC. You just have to make sure you did your homework, just like
when you design your FSM in the first place. A small mistake in the FSM
can work great in simulation and even on the test bench, but end up
failing in the field and lock up the whole thing. I can vouch for
that.

One circuit you can add to any FSM to provide a sync reset is just one
or a pair of FFs which work just like a metastability reduction
circuit. Have the GSR hold these FFs in the '1' state and wire the D
input of the first one to a '0'. The last output will be your sync
reset. The sync reset will be held for one or two clock edges after the
release of GSR. This will only need to be used by the first two bits of
a one-hot FSM, the first changed bit of a gray coded counter, the first
bit of a JRC or even the first bit of a binary counter (assuming it
starts at 0); and so will not overly complicate them and slow them
down.
To me this seems like Chaos**n. Not that it will not work,
it just adds more details you need to manage.

Yes, more details, but each one is separate. If you have startup
dependancies between your FSMs, that has to be managed even if you have
a global sync reset. This does not change that.

This methodology would have to buy me something significant
(speed or device size) for me to want to do additional
analysis and verification to prove that a circuit designed
as above actually works under all conditions.

Speed is just what it is about. If you have to add another input to
every FF on the chip (some of which don't have a lut if they are just
delay registers) I can assure you that many of them will end up adding a
layer of logic and therefore another increment of delay. If your design
is not timing critical, then this is not an issue.

If this is possible, is there a VHDL coding methodology
that you can recommend? The big missing piece for me
is how do I access the output of GSR?


This is something that should be added to Peter's app note.


#1: Explicitly through instantiation?
#2: Implicitly through initializing the VHDL
signals that create the registers?
Although this technique seems possible in XST,
would it also work the same in other synthesis tools?
#3: Put the reset logic in a separate hierarchical
block and explicitly code an asynchronous reset, but
at the next level of the design tie the asynchronous
reset to a constant inactive value?


You don't need to access the GSR signal explicitly. If you provide an
async reset control that is common to most/all of your sequential logic,
I believe the tools will infer the GSR.

run_en_reg: PROCESS (sysclk, reset) BEGIN
IF (reset = '1') THEN
run_en <= '0';
ELSIF (rising_edge(sysclk)) then
run_en <= '1';
END IF;
END PROCESS;

This sounds like it would address my needs nicely.
What do you connect reset to? Do you just leave
it floating? What do you do with it in simulation?

That depends on the target and tools. Many HDL packages will detect the
async reset and connect it to the GSR, similar to the way they detect
clock signals and use the global clock buffers. Some may still require
instantiation of an internal async reset signal source. Check with your
tool/chip vendor.

If there is something here that would work with
XST, Synplicity, and Mentor, without changing the
code, this would make me happy. Especially if
the only thing I needed to change for each FPGA/ASIC
technology is the reset block and where the power-on
reset comes from.

The above style is what I learned to use before anyone was providing any
automatic support. You used to need to instantiate the driver for this
signal or even provide it at a schematic level at the top of the
design. As far as I know all vendors support this, but check with the
tool vendor to be sure. Don't they have style guides?

You can learn a lot about it by reading how the end of configuration
works. But the main thing is to stop assuming that the end of GSR is a
synchronous event. On other chips we get used to the reset just working
(like magic). In the FPGA we need to give it a little thought, even if
it is not really hard.
On ASICs reset is explicit. On your flow above with Xilinx,
I code reset on the register, hook it to ?? or leave it
unconnected, and then "magically" it gets connected to GSR.

Is there a datasheet, manual, or appnote you recommend reading
on configuration.

I don't know which app note would be good, but Xilinx has lots of them.
Do a doc search on their web site on the line of chips you are using and
the word "startup" or "configuration".

--

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design URL http://www.arius.com
4 King Ave 301-682-7772 Voice
Frederick, MD 21701-3110 301-682-7666 FAX

 

[Jim Lewis]

Peter,
As an ASIC designer, I understand the fundamental issues
with propagating signals - including reset deassertion.
I also understand VHDL quite well.

What is not clear to me is the relationship between
my code, my reset, and Xilinx GSR after synthesis.
The following code specifies a single reset:

process (Clk, nReset)
begin
if nReset = '0' then
Y <= '0' ;
elsif rising_edge(Clk) then
Y <= A ;
end if ;
end process ;

What I think I am hearing is that after synthesis
targeting Xilinx technology, the reset of the register
is connected to both GSR and my nReset signal. My
nReset signal typically comes from a block which
resynchronizes it similar to how Ken Chapman recommends.

Am I right so far? I am scanning through your Basic
VHDL document. Since I know VHDL quite well, I would
not normally read this document. I see the above
conclusions in the resulting logic equations, however,
I do not see it in written text. Is there another
document that explains this?

Going further, how do I write VHDL that will reset a
register using GSR, but not an require external reset?
It sounds like what I am hearing (rickman) is
that I code it like above and tie the nReset
signal to '1' (or leave it unconnected?) and GSR will
remain connected to the FF after synthesis.

Is this part right?
I am not real comfortable with this part of the process
as in ASIC synthesis, if you tie the nReset signal
inactive then it is likely to remove that function
from the register. If this is what you really do,
it is so foreign to me that I need to hear it again
and again in your documentation.

Once I know the correct method for the above, I
too can be as smart as the other smart designers
dealing with this issue.

Best Regards,
Jim

Let me get back to the fundamental problem:
We distribute a (p)reset signal all over the chip. The problem is not the
activating edge of this signal, it's the release of (p)reset. No matter how
we distribute and phase it (unless there is only a single user clock of
relatively low frequency) the trailing edge will not appear at every
flip-flop in the same clock period. Whether the (p)reset is asynchronous or
synchronous does not matter. I do not see a way to solve this dilemma on the
chip-hardware-design level.
I suppose the software could be made smart enought to handle this, same as
smart designers can design around this. Especially with an elegant construct
like SRL16.
Peter Alfke


From: Jim Lewis <Jim@SynthWorks.com
Organization: Posted via Supernews, http://www.supernews.com
Newsgroups: comp.arch.fpga,comp.lang.vhdl
Date: Wed, 14 Jul 2004 12:01:13 -0700
Subject: Re: FSM in illegal state (conclusion)

Rick,

These circuits are typically FSM, counters and the like.
Normally the data path does not care about reset since it
will immediately go to the correct state on the next clock.

I am a former ASIC designer. I think I understand this
part well. I do have a couple concerns. First I want a
reset methodology that is device independent and
simulates well for any ASIC or FPGA technology not
just specific to Xilinx. Hence, everything that requires
reset will need the synchronized reset. I agree most
data path does not need reset (except for on some ASIC designs
to get the device to pass vectors more easily on the tester).

My second concern is that selective reset is not for
everyone. For some this methodology will cause chaos.
For a design review with selective reset, this is just
one more item that needs to be reviewed in detail.



One circuit you can add to any FSM to provide a sync reset is just one
or a pair of FFs which work just like a metastability reduction
circuit. Have the GSR hold these FFs in the '1' state and wire the D
input of the first one to a '0'. The last output will be your sync
reset. The sync reset will be held for one or two clock edges after the
release of GSR. This will only need to be used by the first two bits of
a one-hot FSM, the first changed bit of a gray coded counter, the first
bit of a JRC or even the first bit of a binary counter (assuming it
starts at 0); and so will not overly complicate them and slow them
down.

To me this seems like Chaos**n. Not that it will not work,
it just adds more details you need to manage.

This methodology would have to buy me something significant
(speed or device size) for me to want to do additional
analysis and verification to prove that a circuit designed
as above actually works under all conditions.



If this is possible, is there a VHDL coding methodology
that you can recommend? The big missing piece for me
is how do I access the output of GSR?


This is something that should be added to Peter's app note.



#1: Explicitly through instantiation?
#2: Implicitly through initializing the VHDL
signals that create the registers?
Although this technique seems possible in XST,
would it also work the same in other synthesis tools?
#3: Put the reset logic in a separate hierarchical
block and explicitly code an asynchronous reset, but
at the next level of the design tie the asynchronous
reset to a constant inactive value?


You don't need to access the GSR signal explicitly. If you provide an
async reset control that is common to most/all of your sequential logic,
I believe the tools will infer the GSR.

run_en_reg: PROCESS (sysclk, reset) BEGIN
IF (reset = '1') THEN
run_en <= '0';
ELSIF (rising_edge(sysclk)) then
run_en <= '1';
END IF;
END PROCESS;

This sounds like it would address my needs nicely.
What do you connect reset to? Do you just leave
it floating? What do you do with it in simulation?

If there is something here that would work with
XST, Synplicity, and Mentor, without changing the
code, this would make me happy. Especially if
the only thing I needed to change for each FPGA/ASIC
technology is the reset block and where the power-on
reset comes from.



You can learn a lot about it by reading how the end of configuration
works. But the main thing is to stop assuming that the end of GSR is a
synchronous event. On other chips we get used to the reset just working
(like magic). In the FPGA we need to give it a little thought, even if
it is not really hard.

On ASICs reset is explicit. On your flow above with Xilinx,
I code reset on the register, hook it to ?? or leave it
unconnected, and then "magically" it gets connected to GSR.

Is there a datasheet, manual, or appnote you recommend reading
on configuration.

Cheers,
Jim
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Jim Lewis
Director of Training mailto:Jim@SynthWorks.com
SynthWorks Design Inc. http://www.SynthWorks.com
1-503-590-4787

Expert VHDL Training for Hardware Design and Verification
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Jim Lewis
Director of Training mailto:Jim@SynthWorks.com
SynthWorks Design Inc. http://www.SynthWorks.com
1-503-590-4787

Expert VHDL Training for Hardware Design and Verification
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

 

[Jonathan Bromley]

On Wed, 14 Jul 2004 12:01:13 -0700,
Jim Lewis <Jim@SynthWorks.com> wrote:

[rickman:]

You don't need to access the GSR signal explicitly. If you provide an
async reset control that is common to most/all of your sequential logic,
I believe the tools will infer the GSR.

run_en_reg: PROCESS (sysclk, reset) BEGIN
IF (reset = '1') THEN
run_en <= '0';
ELSIF (rising_edge(sysclk)) then
run_en <= '1';
END IF;
END PROCESS;

This sounds like it would address my needs nicely.
What do you connect reset to? Do you just leave
it floating? What do you do with it in simulation?

If there is something here that would work with
XST, Synplicity, and Mentor, without changing the
code, this would make me happy. Especially if
the only thing I needed to change for each FPGA/ASIC
technology is the reset block and where the power-on
reset comes from.
[...]
On ASICs reset is explicit. On your flow above with Xilinx,
I code reset on the register, hook it to ?? or leave it
unconnected, and then "magically" it gets connected to GSR.

I've always tied-off my global reset to FALSE at the
top level, and tools then seem to infer configuration
values but I'm not sure whether it's the
"recommended" style.

Synth tool vendors could do us a great service by
legitimising VHDL signal initialisation,
*for flip-flops only*, to imply the configuration or power-up
state of a register. You could still use an explicit reset if
you so wish, but the design would then simulate correctly
even if reset was held false throughout. There was quite
a lot of discussion of this in 1076.6 and 1364.1 (VHDL
and Verilog synthesis subset standards) and ISTR it was
eventually rejected on the grounds that not all devices
support it. This mystified me, because there are plenty
other things in the synthesisable subset that are not
universally available (for example, BOTH asynch preset
AND asynch reset on the same register); if you use such a
construct and your target device can't implement it, the
tool must throw at least a warning to inform you.

XST experts please confirm, but I think XST accepts signal
initialisation, and infers configuration value from it.

Clearly this style would not be strictly portable across
target technologies. However, if the tools handle it all
sensibly, you could imagine a coding style that used BOTH
signal initialisation (to represent power-up or config reset)
AND global asynch reset (which could be tied-off FALSE).
Then you need to declare just one global constant:

constant FF_Startup_Value: std_ulogic := '0';
...
architecture RTL of stuff is
signal FF: std_logic := [not] FF_Startup_Value;
process (clk, reset)
if reset='1' then
FF <= '1';
...
Then change the constant to 'U' when targeting a device
that doesn't have reliable power-up values.
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL, Verilog, SystemC, Perl, Tcl/Tk, Verification, Project Services

Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, BH24 1AW, UK
Tel: +44 (0)1425 471223 mail:jonathan.bromley@doulos.com
Fax: +44 (0)1425 471573 Web: http://www.doulos.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.

 

[Duane Clark]

Michael Smith wrote:

Forgive me if I've someone's mentioned it already, but I understand that, in
Virtex and later devices, synthesis tools do NOT infer the use of the GSR
from the VHDL Reset signal. Instead the user's Reset is routed using general
routing resources. (So, timing constraints can be applied to it.) There is
of course still an issue if the external signal is truly asynchronous to the
clock.

I am puzzled by how that would work. In normal use, the reset would be
driven by an internal ROC (in VHDL), or be driven only by the testbench
(in Verilog). So what would be the source of the reset signal in the
cases you mention? Or are you referring to an asynchronous reset driven
from a pin?

--
My real email is akamail.com@dclark (or something like that).

 

[Jonathan Bromley]

On 21 Jul 2004 09:06:01 -0700, patrick.melet@dmradiocom.fr (Patrick)
wrote:

hello,

I have got this error message under Leonardo Spectrum :
- e_r_dsss_v21 contains infinite structural recursion.
e_r_dsss_v21 is my design file write in VHDL.

Your architecture contains an instance of itself.

This may be quite hard to find. Perhaps your
architecture A contains an instance of architecture B,
which contains an instance of architecture A...

It is even more difficult to find if your
architecture INTENTIONALLY contains an instance
of itself. This is possible and useful, but it
must be controlled using generics so that the leaf
instances can be identified and created properly.

The simple advice: Look at every component instance
in your architecture, very carefully. Make sure
you understand what you are trying to do.

If your code is not too big, post it here.

If your code is big, try removing your component
instances one by one. This will give you some
unconnected (floating) signals, of course, but
it will help you to find the broken instance.
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL, Verilog, SystemC, Perl, Tcl/Tk, Verification, Project Services

Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, BH24 1AW, UK
Tel: +44 (0)1425 471223 mail:jonathan.bromley@doulos.com
Fax: +44 (0)1425 471573 Web: http://www.doulos.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.

 

[Sander Vesik]

In comp.arch.fpga Hal Murray <hmurray@suespammers.org> wrote:

What do ASIC/CPU designers do? My guess is that they don't
have a global-reset so their version of this problem is a bit
different.

a cpu "just" needs:
* known good value in the pc
* address translation and caches disabled

thats a very small amount of state that needs to be right. the rest can be
initiated to a known good state by software.

--
Sander

+++ Out of cheese error +++

 

[Jonathan Bromley]

On Thu, 22 Jul 2004 13:11:13 +0100, Jonathan Bromley
<jonathan.bromley@doulos.com> wrote:

I would like to know the vhdl equivalent of verilog trireg.

Depends how much of the Verilog functionality you need to mimic.

[snip lots of vaguely sensible ramblings]

If I remember correctly, Verilog trireg can also offer a
"capacitive decay" behaviour in which its value collapses
to X if it hasn't been updated after some specified time.
You can imitate this using VHDL inertial delay:

my_trireg <= weaken(my_trireg), 'W' after decay_time;

Oh dear, oh dear, oh dear. This doesn't work. It's my
faulty memory of something similar, but slightly different.

Today's challenge (1): what's wrong with it?
Today's challenge (2), harder: how to fix it?

I have a wonderful solution, but the margin of this
lunch break is too short to accommodate it
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL, Verilog, SystemC, Perl, Tcl/Tk, Verification, Project Services

Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, BH24 1AW, UK
Tel: +44 (0)1425 471223 mail:jonathan.bromley@doulos.com
Fax: +44 (0)1425 471573 Web: http://www.doulos.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.

 

[Allan Herriman]

On Thu, 22 Jul 2004 13:11:13 +0100, Jonathan Bromley
<jonathan.bromley@doulos.com> wrote:

On 22 Jul 2004 04:05:46 -0700, sanjeev.chaudhri@gmail.com (Sanjeev)
wrote:

I would like to know the vhdl equivalent of verilog trireg.

[snip]

None of this makes any sense for synthesis, of course.

I assume that you meant to say that it cannot be inferred by current
synthesis tools.
XST, for example, can generate one from HDL source using the "keeper"
attribute (on an I/O pin only, since Xilinx FPGAs no longer have
internal tristate signals).

(Or were you just referring to the decay effect? If this is the case,
I agree with you.)

Regards,
Allan.

 

[Jonathan Bromley]

On Fri, 23 Jul 2004 13:19:44 +1000, Allan Herriman
<allan.herriman.hates.spam@ctam.com.au.invalid> wrote:

On Thu, 22 Jul 2004 13:11:13 +0100, Jonathan Bromley
jonathan.bromley@doulos.com> wrote:

None of this makes any sense for synthesis, of course.

I assume that you meant to say that it cannot be inferred by current
synthesis tools.
XST, for example, can generate one from HDL source using the "keeper"
attribute (on an I/O pin only)

The code I posted is, of course, a "weak keeper" or "bus hold" model.
It was careless of me to say that it makes no sense for synthesis,
since it represents a perfectly reasonable hardware structure;
but I was not aware that any tools could correctly infer such
a structure from the behavioural description. One more gold star
to XST (the first one was for correct handling of initialisation
in the declaration of a flip-flop signal).
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL, Verilog, SystemC, Perl, Tcl/Tk, Verification, Project Services

Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, BH24 1AW, UK
Tel: +44 (0)1425 471223 mail:jonathan.bromley@doulos.com
Fax: +44 (0)1425 471573 Web: http://www.doulos.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.

 

[Jim Lewis]

Weng,

Here is another point your committee should pay attention to:
sensitivity list!

Why don't you propose to change it?

Already did. See the fast track proposals at:
http://www.eda.org/vhdl-200x/vhdl-200x-ft/proposals/proposals.html

See FT-19
It would be better if you would educate yourself about
what the working group is currently doing before
mouthing off like this.

Cheers,
Jim
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Jim Lewis
Director of Training mailto:Jim@SynthWorks.com
SynthWorks Design Inc. http://www.SynthWorks.com
1-503-590-4787

Expert VHDL Training for Hardware Design and Verification
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

 

[Just an Illusion]

Hi Weng,

Weng Tianxiang wrote:

JaI,


process (*) is an aberration. Yes it can be help you to write quickly
your code; but all your simulation and synthesizer tools will go to do
lot of unnecessary work.
And that work against your orif proposal at the end.





The process (*) includes all signals of the design into the sensitivity
list of the process. If you have the following code:





c <= a and b;





myProcess : process (*)
if (resetn='0') then
d <= '0';
elsif (clk'event and clk='1') then
d <= e;
endif;





The process myProcess must be evaluated on each modification of 'a', 'b'
and 'c', event if 'e', 'clk' or 'resetn' are independent of 'a','b' and 'c'



You disagree with your opinion.

I guess that why sensitivity list was introduced into VHDL/Verilog 25
years ago was the consideration to the memory size limit and software
handling limit. At 25 years ago, it was very difficult to pick up the
sensitivity list by software.

Now situations are totally different from 25 years ago. Do we need to
differentiate 3 cases: dff, comp or latch? Software cannot do that? My
deep believe that software can do it now at easy and as much better
and faster than any experienced programmers to pick up any signals
for sensitivity.


I don't know history of sensitivity list, but usage of (*) as sensitive

list can change your expected result

Take codes:

NotLatch : process (g)
begin
if (g='1') then
q<=d;
end if;
end process;

IsLatch : process (*)
begin
if (g='1') then
q<=d;
end if;
end process;

The both are similar, but according to section 12.6 of the lrm, the
first process is a flip-flop and the second (according to verilog
sensitivity notation) must be a d-latch.

You have an other problem, the interpretation queue ordering for the
following code:

process (*)
begin
if (g='1') then
a<= not b;
b<=a;
endif;
end process;

According to verilog notation, it must be equivalent to:
process (g,a,b)
begin
if (g='1') then
a<= not b;
b<=a;
end if;
end process;

But in that case, you have a problem according to section 12.6 of the lrm.
If you have only (g) in sensitivity list, you are safe.

That is an example of danger with (*)

Weng


JaI