I hate VHDL!!!

Nicolas,
'-' is "don't care" (never understood what this stands for, actually),
By differentiating '-' and 'X', it is possible to
do something reasonable for:
Y <= std_match(A, "10---100") ; -- see numeric_std

case1: If A is 10111100 then Y is true.
case2: If A is XXXXXXXX then Y is false.

If there were only 'X' and no '-', then case 2 would
be true. This would be bad. I believe that this is
one if the issues with Verilog's casex.

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
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
"mx" <mx@mx.com> escribió en el mensaje
news:0V4Fc.84714$s25.47872@newssvr29.news.prodigy.com...
<snip>
(c) If the customer is acquired (purchased) by another company, the
EDA-software is non-transferrable.
and could somebody tell why's that? the furniture guys dont expect the new
owner of the company to pay them again for the furniture sitting in the
offices, why would we have to pay then to the software guys?

Thankfully within industry, the
standard practice is for the vendor to permit the ownership transfer, as
long as the new owner continues to pay the maintenance/support contract
obligations. This is cheaper for the new owner, because they don't
have to 're-purchase' the licenses (large one-time non-recurring
expense), rather merely pay the quarterly/yearly support-fee (smaller
recurring expense.)
that's more reasonable...
 
"roller" <trash_nospam@hotmail.com> writes:

"mx" <mx@mx.com> escribió en el mensaje
news:0V4Fc.84714$s25.47872@newssvr29.news.prodigy.com...
snip
(c) If the customer is acquired (purchased) by another company, the
EDA-software is non-transferrable.

and could somebody tell why's that? the furniture guys dont expect the new
owner of the company to pay them again for the furniture sitting in the
offices, why would we have to pay then to the software guys?
You *buy* furniture, you *license* software. The devil is in the
lawyers^Wdetails.

Thankfully within industry, the
standard practice is for the vendor to permit the ownership transfer, as
long as the new owner continues to pay the maintenance/support contract
obligations. This is cheaper for the new owner, because they don't
have to 're-purchase' the licenses (large one-time non-recurring
expense), rather merely pay the quarterly/yearly support-fee (smaller
recurring expense.)
Yup, that's my experience as well.

Regards,


Kai
 
Hi Mike,

Mike Treseler wrote:

Just an Illusion <illusion_to_net@yahoo.fr> wrote in message news:<40E12835.5020807@yahoo.fr>...


Hi Chao,

Or use a type.

type FOO is ("VARIABLE", "FIXED", "LONG"...);

it is equivalent to Mike's proposal about integers.



The only difference is that types string and integer
are built-in. Type foo would need a package and USE clause.


Not necessarily, because type can be defined into the
architecture_declarative_part
That limit is usage to the current architecture, but it can be enought.;-)

-- Mike Treseler


JaI
 
Hi Weng

Weng Tianxiang wrote:

snip

4. with physical limit: like reading vs. writing, ...; Memory_1G vs.
Memory_2G, ...;



Sorry but example of read vs. write is not a good example, remember case
of double access ram, where you can have a read and a write access
simultaneously.
More, lot of example have 2 different lines, one for read and another
for write; even if only one must be active at a time.

 
Pino a écrit:
[...]
Thanks this helps clarify the notational details I was trying to think
about. Although from the above example it definitely seems that the
correct way to do this is defining other input & output ports so that
you can tie the shared data bus onto something that can be used to
observe the data (i.e. the Y signal) when it is READ from the memory
and a data line that is required to place data (i.e A) for a WRITE on
the data bus. I had assumed that there was another way to do this.
What I wrote (and I think most VHDL writers do too :eek:) is a description
of how it is actually done in hardware: you have an output buffer with a
tristate control input, and an input buffer:

_____ OE
|
|/|
___/ |___ A
| \ |
| \|
Z --|
| |\
|___| \___ Y
| /
|/


Also just a point of additional confusing concerning OE. Is the OE
enable line absolutely required, or if in certain portions of my state
machine if I absolutely know that I'm going to READ and WRITE (ie I'm
in that logical state), can I just ignore the inclusion of this
additional input signal and place the data on the line and/or read the
data from the line and store it directly into Y or take the data
directly from A?
Y will always take data from Z. Always assign a value to A. Enable the
output (i.e. assert OE) only when you really output data.
The two lines I wrote must be placed only in the top-level VHDL file
(well not really "must" but it's more adviseable)


--
____ _ __ ___
| _ \_)/ _|/ _ \ Adresse de retour invalide: retirez le -
| | | | | (_| |_| | Invalid return address: remove the -
|_| |_|_|\__|\___/
 
yes, RXC generator from clk16x is in the same FPGA and I could get
that signal rxcedge. Because of this my delay of the output will now
be 1 clk16x cycle rather than 2 clk16x cycles. As clk16x is 16 times
faster than RXC I think 1 clk16x should not be a problem. Thanks for
the suggestion..
You should be able to make it with no delay at all! Notice that the rxcedge
signal is '1' the cycle BEFORE the falling edge of RXC. On the rising edge
of clk16x that follows, the RXC generator will set RXC <= '0' and the
trensceiver process will shift its register - both at the same time. The
example I provided works like that.

Just for curiosity which is the better method? to use signal like
clkedge or give the derived clock to the flip flop..
Well, personally I always try to avoid multiple clocks since it's always a
headache to ensure that the signals between flip-flops on different clocks
are stable in time. So I would clearly use the clkedge signal. But for
someone who's experienced in using multiple clocks (unlike me), it might be
an option to use RXC as a second clock. After all, the code becomes clearer
and more compact. So to answer you question, I guess it's a matter of
personal taste!

/Jerker
 
Just an Illusion wrote:

Not necessarily, because type can be defined into the
architecture_declarative_part
That limit is usage to the current architecture, but it can be enought.;-)
The OP was discussing an entity generic.

-- Mike Treseler
 
BlueDoze wrote:

I'd like to know how the VHDL record type and array type is
synthesized, assuming all the field are synthesizable ?
It depends on your code.
A record or array type could represent rom or ram,
a set of registers, or an intermediate value.
The job of synthesis
is to provide a netlist that sims the
same as the source code.

Consider keeping entities simple
and use the complex types in processes
or architectures.

-- Mike Treseler
 
Oleg wrote:
Hi, my question is very simple but i cant find any answer to it juste
loocking at xilinx site or reading there data sheets.
My question is :
Do any one have an exemple of template for instantiating xilinx Virtex
II single ported RAMB16_S2,RAMB16_9 and RAMB16_S18
Look in the Xilinx directory:

vhdl/unisim/unisim_VCOM.vhd

not 100% sure of the filename and path but it is the unisim library you
want.
--
Tim Hubberstey, P.Eng. . . . . . Hardware/Software Consulting Engineer
Marmot Engineering . . . . . . . VHDL, ASICs, FPGAs, embedded systems
Vancouver, BC, Canada . . . . . . . . . . . http://www.marmot-eng.com
 
Oleg wrote:
Hi, my question is very simple but i cant find any answer to it juste
loocking at xilinx site or reading there data sheets.
My question is :
Do any one have an exemple of template for instantiating xilinx Virtex
II single ported RAMB16_S2,RAMB16_9 and RAMB16_S18
Look here:

http://toolbox.xilinx.com/docsan/xilinx5/data/docs/lib/lib0027_11.html

There's example instantiations for all Virtex design elements.

cu,
Sean
 
Hi Weng,

Weng Tianxiang wrote:

JaI,


Sorry but example of read vs. write is not a good example, remember case
of double access ram, where you can have a read and a write access
simultaneously.



If you don't know something, it is better to keep quite and stand
aside to learn.


You are not the only people which made design, so be quiet.

Tell me what kind of double access ram working in a way a read and a
write access happen simultaneously.


Fifo between two different clock domains is the most classical case.
Read and write are fully independant, and can be done simultaneously.

It is not because you don't do it that nobody does.

 
How is the reset signal handled? If the FFs are asynchronously reset,
then the end of reset can happen at different times to different FFs,
leading to an illegal state.
Hi Phil! I use no reset signal at all; instead I specify initial values
for all signals by the declarations, which is supposed to work fine with
XST. But your point is still interesting in case I would need to
introduce an asynchronous reset some day. Does that mean one should
avoid them if illegal states are a concern?

/Jerker
 
Internal noise coupling in the chip (crosstalk), power drops, alpha
particles, not properly double-sync'ing an async signal before using
it in two different places (BTDT, seen it in a real chip), ... the
list goes on!
OK, probably I would need the complete list with full descriptions! Do
you know of any books or tutorials on this subject? I'm not really an
electrical engineer but I have to deal with this, so any pointers would
be appreciated.

/Jerker
 
rickman wrote:
I am unclear as to why the others clause would not result in recovery
from an illegal state. That could very easily add a lot of extra logic
and even slow the max speed of the FSM. But it should not be optimized
away since it is a specified part of the machine. I assume the illegal
state detection works in simulation, no? If so, it should work in
operation.
The synthesis tools are "smart" enough to recognize that there is no
logical way to reach the "others" state. Therefore it is optimized out.
Many synthesis tools do this.

--
My real email is akamail.com@dclark (or something like that).
 
Hi Jerker,
Well, you _do_ have a reset. It's just a little hidden. At some point the
storage elements stop being held at the initial values. This is the
equivalent of your reset being released. If the elements are being clocked
asynchronously to the release signal at this time, you could be in trouble.
Cheers, Syms.
"Jerker Hammarberg (DST)" <jerkerNO@SPAMdst.se> wrote in message
news:hzZGc.4458$dx3.36217@newsb.telia.net...
How is the reset signal handled? If the FFs are asynchronously reset,
then the end of reset can happen at different times to different FFs,
leading to an illegal state.

Hi Phil! I use no reset signal at all; instead I specify initial values
for all signals by the declarations, which is supposed to work fine with
XST. But your point is still interesting in case I would need to
introduce an asynchronous reset some day. Does that mean one should
avoid them if illegal states are a concern?

/Jerker
 
Duane Clark wrote:
rickman wrote:


I am unclear as to why the others clause would not result in recovery
from an illegal state. That could very easily add a lot of extra logic
and even slow the max speed of the FSM. But it should not be optimized
away since it is a specified part of the machine. I assume the illegal
state detection works in simulation, no? If so, it should work in
operation.


The synthesis tools are "smart" enough to recognize that there is no
logical way to reach the "others" state. Therefore it is optimized out.
Many synthesis tools do this.
Wow, isn't software clever... and it probably does not tell you it did
this either... but never mind, the other state have no logical pathways,
so everything will be OK.

Back to the real engineering world:
Do LOOK at the resultant output of your tools, and HOW it actually
built the FSM. It can use .D or .T registers, with .D the most common.

Implicit in most .D coding is that state 00000 is the goto state from
any illegal ones : Thus for many reasons (hopefully very rare) you MIGHT
goto an illegal state, but the one after that will be 00000.

This should be a cornerstone state of your legal state list, either
the POR state, or the safe-idle state.

Choosing gray code related states can reduce the pathways to illegal
states, but in complex FSM's, this is not always possible.

You should not rely on this recovery pathway in regular system
operation, it should be a safety-net.
During tests, you could INC a counter when passing through 00000,

..T register state engines can be smaller, but they also can literally
stick at an illegal state.

-jg
 
Hi Rick, thanks for your reply!

1) electrical noise which would also cause upset of *other* FFs in the
system causing other symptoms and
I don't think I can rule that out in this specific application. But
where, that is on what physical signal, do you mean the electrical noise
would occur, and how could it affect the FPGA's internal state?

2) timing issues with the FSM. This can be either from async inputs
(metastability) or from failing to meet setup time on a reg input. If
you have done your static timing analysis correctly, then it must be a
metastability issue. The fact that it occurs happens on startup says
to me it is a timing issue. If you can chase the problem away by
slowing your clock, then it is a static timing issue. If it persists,
then you most likely have a metastable issue.
I doubt that it's about static timing in my case since my clock is 20
MHz, and XST's post-layout static timing analysis doesn't complain.
Metastability could be an issue, but it's strange that it happens so
often. On one particular design, it happens about once every ten times i
startup the system. All inputs are synchronized with one FF each, but
I'll try adding a second one to see if it helps.

I am not a fan of dealing with this type of problem by illegal state
recognition. If it gets into an illegal state it has already caused a
malfunction of the rest of the circuit most likely. Getting back to a
known state is only useful in that it can resume normal operation.
But it is not a "fix".
I agree totally, that's why I pointed out that most previous threads
dealt with recovery from but not with the cause of illegal states.

I am unclear as to why the others clause would not result in recovery
from an illegal state. That could very easily add a lot of extra
logic and even slow the max speed of the FSM. But it should not be
optimized away since it is a specified part of the machine. I assume
the illegal state detection works in simulation, no? If so, it should
work in operation.
Well, the FSM optimizer detects unreachable and removes related logic,
and I guess that's what's happening here too. Indeed, if I simulate the
RTL code as it is, I can't put the design in an illegal state - there is
simply no signal that I can force to an illegal value. But if I add a
dummy state in the enumerated state type definition without adding a
"when" clause for it, then I can enforce the dummy state and the "when
others" clause is applied. If I simulate the post-layout code, I would
be very surprised if the illegal state detection worked since it was
taken away during synthesis, but I haven't tried it.

/Jerker
 
Hi Jim!

Do LOOK at the resultant output of your tools, and HOW it actually
built the FSM. It can use .D or .T registers, with .D the most common.
Well, the output netlist isn't exactly human-readable, although I guess
I could write a simple FSM, synthesize it and study it. But actually I
already know how XST has encoded my machine. My options are essentially
One-Hot, Compact (binary), Sequential, Gray, and Johnson, all presumably
on D flip-flops. I get One-Hot encoded machines unless i ask for
something else.

However, correct me if I'm wrong, the state encoding itself doesn't
change anything in the machine's ability to recover from illegal states
- it takes some logic that detects these illegal states and forces the
state vector back to normal, and that logic obviously isn't there. Many
synthesis tools provide an extra option "safe FSMs" which will add such
logic, but XST doesn't. So my question is XST-specific - how do I add
illegal state recovery logic with XST?

/Jerker
 
Jerker Hammarberg (DST) wrote:

Hi Jim!

Do LOOK at the resultant output of your tools, and HOW it actually
built the FSM. It can use .D or .T registers, with .D the most common.

Well, the output netlist isn't exactly human-readable, although I guess
I could write a simple FSM, synthesize it and study it. But actually I
already know how XST has encoded my machine. My options are essentially
One-Hot, Compact (binary), Sequential, Gray, and Johnson, all presumably
on D flip-flops. I get One-Hot encoded machines unless i ask for
something else.

However, correct me if I'm wrong, the state encoding itself doesn't
change anything in the machine's ability to recover from illegal states
- it takes some logic that detects these illegal states and forces the
state vector back to normal, and that logic obviously isn't there.
No, not quite.
If you consider .D registered FSMs, then if you have enumerated 00000
as a legal state, that naturally maps what you call recovery logic.
If the tools choose one-hot, and take 00000 as illegal/not possible,
(since it is not a one-hot state) then you loose the natural recovery path.
ie the state encoding itself CAN affect the recovery, as if you
avoid the .D recovery path of all low, your FSM will not perform
the same as one that includes all lows as a specified state.

Try Gray or Johnson, and make sure the 00000 is an enumerated/specified
state, and see what happens ?

-jg
 

Welcome to EDABoard.com

Sponsor

Back
Top