R
Robert Miles
Guest
"GDI teambuilder" <news@seegers.ws> wrote in message
news:zcqTi.11178$fA2.81@nntpserver.swip.net...
news:zcqTi.11178$fA2.81@nntpserver.swip.net...
to do.
Navigation
Install the app
How to install the app on iOS
Follow along with the video below to see how to install our site as a web app on your home screen.
Note: This feature may not be available in some browsers.
More options
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an alternative browser.
You should upgrade or use an alternative browser.
Guest
MYH wrote:
simple token, and you cannot use an expression for it.
However, you can use an expression that has the appropriate width and
value. The replication operator is particularly useful for this:
{ {(`n-2){1'b0}}, 2'b10}
That is a 2-bit 2'b10, concatenated onto `n-2 zeroes.
As someone else suggested, for most purposes you can just use the
value 2 and not worry about the width. If you are concerned about
warnings for width mismatches, and these are only issued for
truncation, you can use the narrowest possible width 2'b10. This will
be extended automatically to the width of the expression before being
used.
You cannot do this directly. The size of a numeric literal is aHi.
How to specify the size of a number by a define macro expression?
For example:
---------------------------------------------------------------------
`define m 1
`define n (`m+1)
Then `n'b10 will expand to `m+1'b10.
And `m+1'b10 will expand to 1+1'b10 (This is a 32bit 1 plus a 1bit 0!)
But I really want this number: 2'b10
How do I solve this problem?
simple token, and you cannot use an expression for it.
However, you can use an expression that has the appropriate width and
value. The replication operator is particularly useful for this:
{ {(`n-2){1'b0}}, 2'b10}
That is a 2-bit 2'b10, concatenated onto `n-2 zeroes.
As someone else suggested, for most purposes you can just use the
value 2 and not worry about the width. If you are concerned about
warnings for width mismatches, and these are only issued for
truncation, you can use the narrowest possible width 2'b10. This will
be extended automatically to the width of the expression before being
used.
G
gabor
Guest
On Feb 19, 10:39 am, MikeShepherd...@btinternet.com wrote:
wire [`m:0] const_two = 2;
assign c = ( a == const_two );
It's a little clunky, but I've used this approach when I wasn't
sure how an expression would be sized. And wires don't add
any hardware to the synthesis. You might still get the size
warning (XST doesn't warn in this case, but I don't know about
Quartus II) for the initialization assignment.
You could also just create wires for your sized constants like...If you don't assign a size to a number, and compare the number to a
variable, for example...then Quartus II will synthesize out a 32 bit
comparator (in RTL Viewer).
This wastes the hardware resources. I only need a 2 bit comparator.
The 32-bit comparator may show up in the RTL viewer, but you can be
sure that it will be gone in the implementation. (In Quartus, select
View / Technology Map Viewer).
The RTL viewer reflects closely what you wrote. For example, if in
your HDL you add one to a register, the RTL will show that register
fed from an adder whose inputs are the same register and a constant
field of the same length with value 1. Despite this, the
implementation is a counter.
Mike
wire [`m:0] const_two = 2;
assign c = ( a == const_two );
It's a little clunky, but I've used this approach when I wasn't
sure how an expression would be sized. And wires don't add
any hardware to the synthesis. You might still get the size
warning (XST doesn't warn in this case, but I don't know about
Quartus II) for the initialization assignment.
G
gabor
Guest
On Feb 17, 2:54 am, "MYH" <93501...@cc.ncu.edu.tw> wrote:
will just take the appropriate number of LS bits from the constant
anyway. So:
reg [1:0] p = 'b10;
or :
reg [1:0] p = 2;
would only take the 2 LSB's of the constant as required by the 2-bit
reg "p". But perhaps you have another case where the size of the
constant affects the expression?
Regards,
Gabor
Is there a good reason to size the constant? Normally the assignmentHi.
How to specify the size of a number by a define macro expression?
For example:
---------------------------------------------------------------------
`define m 1
`define n (`m+1)
// The following line will get a compilation error in ModelSim.
// Because (1+1)'b10 is a error syntax.
reg [1:0] p = `n'b10;
---------------------------------------------------------------------
But if you change the n to `m+1, that is:
---------------------------------------------------------------------
`define m 1
`define n `m+1
---------------------------------------------------------------------
Then `n'b10 will expand to `m+1'b10.
And `m+1'b10 will expand to 1+1'b10 (This is a 32bit 1 plus a 1bit 0!)
But I really want this number: 2'b10
How do I solve this problem?
Thanks.
will just take the appropriate number of LS bits from the constant
anyway. So:
reg [1:0] p = 'b10;
or :
reg [1:0] p = 2;
would only take the 2 LSB's of the constant as required by the 2-bit
reg "p". But perhaps you have another case where the size of the
constant affects the expression?
Regards,
Gabor
Guest
In some tools, the size mismatch gives a warning which can beIs there a good reason to size the constant? Normally the assignment
will just take the appropriate number of LS bits from the constant
anyway...
suppressed only by doing so for the whole of the compilation unit.
This often gives a choice between:
1) Ignore all warnings (because there are too many to examine
separately, so any important warning is lost in the noise).
2) Supress the warning all the time (and so it's not shown even when
you need to see it).
In my limited experience so far of compilers for logic, I have the
impression that those who write them spend little time using them or
examining how software compilers have operated for years to eliminate
warning "noise".
Mike
R
Robert Miles
Guest
<nanyangrose@live.cn> wrote in message
news:f1438780-952d-4984-b902-13a6f7253e33@c4g2000hsg.googlegroups.com...
news:f1438780-952d-4984-b902-13a6f7253e33@c4g2000hsg.googlegroups.com...
We are a wholesaler of fake Handbags Shoes Women's Shoes Men's Shoes
Buy one pair of shoes or two bags, free shipping of spam!!
My Website: http://www.china-spammer.conm
R
Robert Miles
Guest
"Samantha" <samantha@incomewhilehome.com> wrote in message
news:UNvsj.34023$FA.2521@pd7urf2no...
news:UNvsj.34023$FA.2521@pd7urf2no...
addresses to send spam to.Are you looking for a job?
Do you like to work from your home using your computer?
Then this might be something for you. It is all about online surveys and
more.
Please visit our website http://www.incomewhilehome.con for more
information.
Thanks for looking.
Watch out - such requests often come from spammers looking for more
M
MYH
Guest
<MikeShepherd564@btinternet.com>
I found after the implementation, Quartus will optimize the comparator to a
simpler circuit.
For example, the following two modules are optimized to the same circuit
which can be viewed by Technology Map Viewer, even though RTL view are not
the same.
-----------------------------------------------------------------------
module Compare( a, b );
output reg a;
input [1:0] b;
always@( * )
if( b == 1 )
a = 0;
else
a = 1;
endmodule
-----------------------------------------------------------------------
-----------------------------------------------------------------------
module Compare2( a, b );
output reg a;
input [1:0] b;
always@( * )
if( b == 2'b1 )
a = 0;
else
a = 1;
endmodule
-----------------------------------------------------------------------
Thank you. I see....If you don't assign a size to a number, and compare the number to a
variable, for example...then Quartus II will synthesize out a 32 bit
comparator (in RTL Viewer).
This wastes the hardware resources. I only need a 2 bit comparator.
The 32-bit comparator may show up in the RTL viewer, but you can be
sure that it will be gone in the implementation. (In Quartus, select
View / Technology Map Viewer).
I found after the implementation, Quartus will optimize the comparator to a
simpler circuit.
For example, the following two modules are optimized to the same circuit
which can be viewed by Technology Map Viewer, even though RTL view are not
the same.
-----------------------------------------------------------------------
module Compare( a, b );
output reg a;
input [1:0] b;
always@( * )
if( b == 1 )
a = 0;
else
a = 1;
endmodule
-----------------------------------------------------------------------
-----------------------------------------------------------------------
module Compare2( a, b );
output reg a;
input [1:0] b;
always@( * )
if( b == 2'b1 )
a = 0;
else
a = 1;
endmodule
-----------------------------------------------------------------------
The RTL viewer reflects closely what you wrote. For example, if in
your HDL you add one to a register, the RTL will show that register
fed from an adder whose inputs are the same register and a constant
field of the same length with value 1. Despite this, the
implementation is a counter.
Mike
J
John_H
Guest
On Mar 17, 10:45 am, FPGA <FPGA.unkn...@gmail.com> wrote:
design for, both filling and emptying the FIFO. Without a limit on
the input fill rate, you need an infinite-sized FIFO. So - figure out
your limits and design your FIFO based on max fill and min empty rate
conditions. Otherwise, FIFOs *can* be straight-forward. Synchronous
FIFOs are easier if the 320 MHz and 40 MHz domains are precisely
aligned but Gray code based FIFOs for asynchronous domains aren't too
much worse as long as you don't need to cut the delay for a new value
to the absolute minimum time possible; an extra clock of delay makes
things work beautifully.
- John_H
You need to know at what average and what burst rates you need toI wish to design a FIFO to tansfer data from a high speed clock
domain(320 MHz) to low speed clock domain(40 Mhz). I dont wish to use
the cores available from any of the vendors.
Inputs =
DataIn // 16 bit data input that is latched in on the posedge of
clkHigh when Wen is high
Wen // Write enable to strobe in the data into the register
Ren // read enable strobe to let the reg know data was read
out of the DataOut register
clkHigh // High speed clock for writing data in
clkLow // low speed clock for reading data out
Outputs =
DataOut // 16 bit data out that is changed to the next value (or
all low if nothing is yet stored inside) when Ren
goes low after toggling high based on the clkL
Full // signal goes high when all input registers are filled
up.
Empty // Goes high when nothing
How to decide on the depth of register DataOut to ensure that data is
not overwritten. The issue is that the FIFO has to have some high
speed storage capacity to allow for more data coming in then was
written out.
Any suggestions would be appreciated.
design for, both filling and emptying the FIFO. Without a limit on
the input fill rate, you need an infinite-sized FIFO. So - figure out
your limits and design your FIFO based on max fill and min empty rate
conditions. Otherwise, FIFOs *can* be straight-forward. Synchronous
FIFOs are easier if the 320 MHz and 40 MHz domains are precisely
aligned but Gray code based FIFOs for asynchronous domains aren't too
much worse as long as you don't need to cut the delay for a new value
to the absolute minimum time possible; an extra clock of delay makes
things work beautifully.
- John_H
F
FPGA
Guest
On Mar 17, 1:55 pm, John_H <newsgr...@johnhandwork.com> wrote:
FIFO is for synchronization between the 2 clock domains.
The FIFO is 16 bits wide and 8 words deep. The purpose of using thisOn Mar 17, 10:45 am, FPGA <FPGA.unkn...@gmail.com> wrote:
I wish to design a FIFO to tansfer data from a high speed clock
domain(320 MHz) to low speed clock domain(40 Mhz). I dont wish to use
the cores available from any of the vendors.
Inputs =
DataIn // 16 bit data input that is latched in on the posedge of
clkHigh when Wen is high
Wen // Write enable to strobe in the data into the register
Ren // read enable strobe to let the reg know data was read
out of the DataOut register
clkHigh // High speed clock for writing data in
clkLow // low speed clock for reading data out
Outputs =
DataOut // 16 bit data out that is changed to the next value (or
all low if nothing is yet stored inside) when Ren
goes low after toggling high based on the clkL
Full // signal goes high when all input registers are filled
up.
Empty // Goes high when nothing
How to decide on the depth of register DataOut to ensure that data is
not overwritten. The issue is that the FIFO has to have some high
speed storage capacity to allow for more data coming in then was
written out.
Any suggestions would be appreciated.
You need to know at what average and what burst rates you need to
design for, both filling and emptying the FIFO. Without a limit on
the input fill rate, you need an infinite-sized FIFO. So - figure out
your limits and design your FIFO based on max fill and min empty rate
conditions. Otherwise, FIFOs *can* be straight-forward. Synchronous
FIFOs are easier if the 320 MHz and 40 MHz domains are precisely
aligned but Gray code based FIFOs for asynchronous domains aren't too
much worse as long as you don't need to cut the delay for a new value
to the absolute minimum time possible; an extra clock of delay makes
things work beautifully.
- John_H- Hide quoted text -
- Show quoted text -
FIFO is for synchronization between the 2 clock domains.
J
John_H
Guest
On Mar 17, 11:03 am, FPGA <FPGA.unkn...@gmail.com> wrote:
don't know how to design a FIFO from scratch since you don't want to
use a core?
Please specify if the domains are 100% synchronous or if they're
asynchronous. If you can't guarantee phase alignment of the two
domains, consider it asynchronous.
Please verify that you want the empty flag on the read side and the
full on the write side.
Specify whether you're a VHDL or Verilog engineer.
What family and vendor is your FPGA? Do you want to target a specific
memory type (such as CLB SelectRAM or M512 RAMs)?
You're no stranger to the board so this doesn't appear to be homework;
why avoid the cores?
- John_H
So if you know it's 8 words deep, what's the problem? Is it that youOn Mar 17, 1:55 pm, John_H <newsgr...@johnhandwork.com> wrote:
On Mar 17, 10:45 am, FPGA <FPGA.unkn...@gmail.com> wrote:
I wish to design a FIFO to tansfer data from a high speed clock
domain(320 MHz) to low speed clock domain(40 Mhz). I dont wish to use
the cores available from any of the vendors.
Inputs =
DataIn // 16 bit data input that is latched in on the posedge of
clkHigh when Wen is high
Wen // Write enable to strobe in the data into the register
Ren // read enable strobe to let the reg know data was read
out of the DataOut register
clkHigh // High speed clock for writing data in
clkLow // low speed clock for reading data out
Outputs =
DataOut // 16 bit data out that is changed to the next value (or
all low if nothing is yet stored inside) when Ren
goes low after toggling high based on the clkL
Full // signal goes high when all input registers are filled
up.
Empty // Goes high when nothing
How to decide on the depth of register DataOut to ensure that data is
not overwritten. The issue is that the FIFO has to have some high
speed storage capacity to allow for more data coming in then was
written out.
Any suggestions would be appreciated.
You need to know at what average and what burst rates you need to
design for, both filling and emptying the FIFO. Without a limit on
the input fill rate, you need an infinite-sized FIFO. So - figure out
your limits and design your FIFO based on max fill and min empty rate
conditions. Otherwise, FIFOs *can* be straight-forward. Synchronous
FIFOs are easier if the 320 MHz and 40 MHz domains are precisely
aligned but Gray code based FIFOs for asynchronous domains aren't too
much worse as long as you don't need to cut the delay for a new value
to the absolute minimum time possible; an extra clock of delay makes
things work beautifully.
- John_H- Hide quoted text -
- Show quoted text -
The FIFO is 16 bits wide and 8 words deep. The purpose of using this
FIFO is for synchronization between the 2 clock domains.- Hide quoted text -
- Show quoted text -
don't know how to design a FIFO from scratch since you don't want to
use a core?
Please specify if the domains are 100% synchronous or if they're
asynchronous. If you can't guarantee phase alignment of the two
domains, consider it asynchronous.
Please verify that you want the empty flag on the read side and the
full on the write side.
Specify whether you're a VHDL or Verilog engineer.
What family and vendor is your FPGA? Do you want to target a specific
memory type (such as CLB SelectRAM or M512 RAMs)?
You're no stranger to the board so this doesn't appear to be homework;
why avoid the cores?
- John_H
F
FPGA
Guest
On Mar 17, 3:19 pm, John_H <newsgr...@johnhandwork.com> wrote:
and low frequencies change.On Mar 17, 11:03 am, FPGA <FPGA.unkn...@gmail.com> wrote:
On Mar 17, 1:55 pm, John_H <newsgr...@johnhandwork.com> wrote:
On Mar 17, 10:45 am, FPGA <FPGA.unkn...@gmail.com> wrote:
I wish to design a FIFO to tansfer data from a high speed clock
domain(320 MHz) to low speed clock domain(40 Mhz). I dont wish to use
the cores available from any of the vendors.
Inputs =
DataIn // 16 bit data input that is latched in on the posedge of
clkHigh when Wen is high
Wen // Write enable to strobe in the data into the register
Ren // read enable strobe to let the reg know data was read
out of the DataOut register
clkHigh // High speed clock for writing data in
clkLow // low speed clock for reading data out
Outputs =
DataOut // 16 bit data out that is changed to the next value (or
all low if nothing is yet stored inside) when Ren
goes low after toggling high based on the clkL
Full // signal goes high when all input registers are filled
up.
Empty // Goes high when nothing
How to decide on the depth of register DataOut to ensure that data is
not overwritten. The issue is that the FIFO has to have some high
speed storage capacity to allow for more data coming in then was
written out.
Any suggestions would be appreciated.
You need to know at what average and what burst rates you need to
design for, both filling and emptying the FIFO. Without a limit on
the input fill rate, you need an infinite-sized FIFO. So - figure out
your limits and design your FIFO based on max fill and min empty rate
conditions. Otherwise, FIFOs *can* be straight-forward. Synchronous
FIFOs are easier if the 320 MHz and 40 MHz domains are precisely
aligned but Gray code based FIFOs for asynchronous domains aren't too
much worse as long as you don't need to cut the delay for a new value
to the absolute minimum time possible; an extra clock of delay makes
things work beautifully.
- John_H- Hide quoted text -
- Show quoted text -
The FIFO is 16 bits wide and 8 words deep. The purpose of using this
FIFO is for synchronization between the 2 clock domains.- Hide quoted text -
- Show quoted text -
So if you know it's 8 words deep, what's the problem? Is it that you
don't know how to design a FIFO from scratch since you don't want to
use a core?
I am not sure if the design would change depending on whether the high
to design my own in either case.Please specify if the domains are 100% synchronous or if they're
asynchronous. If you can't guarantee phase alignment of the two
domains, consider it asynchronous.
Asynchronous.
Please verify that you want the empty flag on the read side and the
full on the write side.
Yes
Specify whether you're a VHDL or Verilog engineer.
Verilog
What family and vendor is your FPGA? Do you want to target a specific
memory type (such as CLB SelectRAM or M512 RAMs)?
I dont want the design to be specific to a particular chip.
You're no stranger to the board so this doesn't appear to be homework;
why avoid the cores?
The cores are not getting simulated with Modelsim XE. And I would like
- John_H- Hide quoted text -
- Show quoted text -
J
John_H
Guest
On Mar 17, 1:29 pm, FPGA <FPGA.unkn...@gmail.com> wrote:
<snip>
So why are you asking us? ;-)
<snip>
And I would like to design my own in either case.
snip
So why are you asking us? ;-)
D
David Spencer
Guest
"FPGA" <FPGA.unknown@gmail.com> wrote in message
news:b799694d-48d2-4ebb-92e4-0953385d8a52@b64g2000hsa.googlegroups.com...
(and I suspect others) provide these free and they've been well tested in
many, many designs. The port names may differ between different vendors but
you can make the FIFO virtually vendor-agnostic by providing a trivial
wrapper to name the ports as you wish.
news:b799694d-48d2-4ebb-92e4-0953385d8a52@b64g2000hsa.googlegroups.com...
If I was you, I really would use a vendor-supplied core. Xilinx and AlteraI wish to design a FIFO to tansfer data from a high speed clock
domain(320 MHz) to low speed clock domain(40 Mhz). I dont wish to use
the cores available from any of the vendors.
(and I suspect others) provide these free and they've been well tested in
many, many designs. The port names may differ between different vendors but
you can make the FIFO virtually vendor-agnostic by providing a trivial
wrapper to name the ports as you wish.
P
Peter Alfke
Guest
On Mar 17, 4:37 pm, "David Spencer" <davidmspen...@verizon.net> wrote:
you face three challenges around the FULL flag:
You must detect FULL fast enough, within a 3 ns period.
And you must release FULL in response to a read clock, without getting
into metastable problems.
And you must compare the two counters without decoding glitches.
All this is stuff the we core designers have solved already for you,
at much higher speed...
Peter Alfke, Xilinx
If for some (strange) reason you want to roll your own,"FPGA" <FPGA.unkn...@gmail.com> wrote in message
news:b799694d-48d2-4ebb-92e4-0953385d8a52@b64g2000hsa.googlegroups.com...
I wish to design a FIFO to tansfer data from a high speed clock
domain(320 MHz) to low speed clock domain(40 Mhz). I dont wish to use
the cores available from any of the vendors.
If I was you, I really would use a vendor-supplied core. Xilinx and Altera
(and I suspect others) provide these free and they've been well tested in
many, many designs. The port names may differ between different vendors but
you can make the FIFO virtually vendor-agnostic by providing a trivial
wrapper to name the ports as you wish.
you face three challenges around the FULL flag:
You must detect FULL fast enough, within a 3 ns period.
And you must release FULL in response to a read clock, without getting
into metastable problems.
And you must compare the two counters without decoding glitches.
All this is stuff the we core designers have solved already for you,
at much higher speed...
Peter Alfke, Xilinx
B
bvkrock
Guest
HI,
I suggest u to once look into elastic buffers may be tht'll help
you...........
I suggest u to once look into elastic buffers may be tht'll help
you...........
J
John_H
Guest
John_H wrote:
http://www.google.com/url?sa=t&ct=res&cd=7&url=http%3A%2F%2Fbooks.google.com%2Fbooks%3Fid%3DaQd4QYNV88EC%26pg%3DPA161%26lpg%3DPA161%26dq%3Dverilog%2Bfifo%2Bgray%26source%3Dweb%26ots%3DfY7n_OHYFN%26sig%3DkArkUjHVCE_M87AwKkrU61gWaz0%26hl%3Den&ei=rr3fR_qqJ5qMiwGyqZjRBQ&usg=AFQjCNGottyhGBvcjXugi1wBigp7dDB8wA&sig2=ormNgEQa4GqcdBc-ULwKxQ
has a reasonable FIFO.
I can't pull one of my FIFOs out of a work file and I did my taxes
yesterday instead of throwing together a FIFO for you.
The flags shouldn't be a big problem for you if you're willing to wait
an extra cycle for the Gray counters to settle out. Having an empty on
the read side means the empty de-asserts only when there's a word has
long since settled in the buffer memory and asserts only in the read
clock's domain. Similarly with the full flag on the transmit side, the
full asserts with the transmit clock but could be a clock worth of delay
late for de-assertion due to the Gray count registration from the read
domain to the write domain.
For a "complete" constraint set, the timing path from the point where
the Gray count is registered in the new timing domain to where the
values are used should be reduced by any metastability delay *or*
registered twice. It would be easy enough to reduce a 25ns period to
23ns or less and not have any significant metastability issues but
cutting down a 3125ps period by 2ns would be miserable. For the 320 MHz
domain, registering the Gray count twice would be a solid way to go.
Gray counters are pretty easy. Handling metastability for these
slow-acting flags is pretty straightforward. What tends to get the
designer is an incorrect FIFO size or a software guy that thinks the way
to clear a FIFO is to just read n words rather than reading until the
empty flag asserts. If the hardware guy doesn't have past-end
read/write handling in place, errant behavior will produce errants.
If after looking at the Google Books example you still aren't sure what
to do, let us know. I can cobble some Verilog together that I'll
happily share, untested.
- John_H
It looks like p171 ofOn Mar 17, 1:29 pm, FPGA <FPGA.unkn...@gmail.com> wrote:
snip
And I would like to design my own in either case.
snip
So why are you asking us? ;-)
http://www.google.com/url?sa=t&ct=res&cd=7&url=http%3A%2F%2Fbooks.google.com%2Fbooks%3Fid%3DaQd4QYNV88EC%26pg%3DPA161%26lpg%3DPA161%26dq%3Dverilog%2Bfifo%2Bgray%26source%3Dweb%26ots%3DfY7n_OHYFN%26sig%3DkArkUjHVCE_M87AwKkrU61gWaz0%26hl%3Den&ei=rr3fR_qqJ5qMiwGyqZjRBQ&usg=AFQjCNGottyhGBvcjXugi1wBigp7dDB8wA&sig2=ormNgEQa4GqcdBc-ULwKxQ
has a reasonable FIFO.
I can't pull one of my FIFOs out of a work file and I did my taxes
yesterday instead of throwing together a FIFO for you.
The flags shouldn't be a big problem for you if you're willing to wait
an extra cycle for the Gray counters to settle out. Having an empty on
the read side means the empty de-asserts only when there's a word has
long since settled in the buffer memory and asserts only in the read
clock's domain. Similarly with the full flag on the transmit side, the
full asserts with the transmit clock but could be a clock worth of delay
late for de-assertion due to the Gray count registration from the read
domain to the write domain.
For a "complete" constraint set, the timing path from the point where
the Gray count is registered in the new timing domain to where the
values are used should be reduced by any metastability delay *or*
registered twice. It would be easy enough to reduce a 25ns period to
23ns or less and not have any significant metastability issues but
cutting down a 3125ps period by 2ns would be miserable. For the 320 MHz
domain, registering the Gray count twice would be a solid way to go.
Gray counters are pretty easy. Handling metastability for these
slow-acting flags is pretty straightforward. What tends to get the
designer is an incorrect FIFO size or a software guy that thinks the way
to clear a FIFO is to just read n words rather than reading until the
empty flag asserts. If the hardware guy doesn't have past-end
read/write handling in place, errant behavior will produce errants.
If after looking at the Google Books example you still aren't sure what
to do, let us know. I can cobble some Verilog together that I'll
happily share, untested.
- John_H
P
Patrick Dubois
Guest
On 18 mar, 01:36, Peter Alfke <al...@sbcglobal.net> wrote:
One reason would be to permit the use of generics. I often use fifos
and I try to use generics whenever possible in the rest of my designs
but unfortunately, coregen fifos are not compatible with generics. I
therefore end up having to create _several_ fifo ngc cores and this is
really a pain in the butt for a large design. We are seriously
considering rolling our own to ease design reuse with generics
(although we haven't yet because we understand that async fifos are
tricky to design, as proven by the V4 bug).
Can we hope to see generic coregen cores one day?
Patrick
One reason would be to permit the use of generics. I often use fifos
and I try to use generics whenever possible in the rest of my designs
but unfortunately, coregen fifos are not compatible with generics. I
therefore end up having to create _several_ fifo ngc cores and this is
really a pain in the butt for a large design. We are seriously
considering rolling our own to ease design reuse with generics
(although we haven't yet because we understand that async fifos are
tricky to design, as proven by the V4 bug).
Can we hope to see generic coregen cores one day?
Patrick
J
John_H
Guest
On Mar 17, 10:36 pm, Peter Alfke <al...@sbcglobal.net> wrote:
Would it be valid to say that if the user doesn't need a(n almost)
full flag on the read side or an (almost) empty flag on the write side
that a FIFO design would be pretty relaxed?
It's often preferred to have flags act as fast as possible in the
"other" clock domain such that adding an extra clock cycle or more in
the read domain after a write or vice-versa isn't an acceptable
solution. I've been able to have my systems work well without this
stressful need.
Or is there more of a nuance that I haven't yet understood?
I appreciate your guidance,
- John_H
Peter,If for some (strange) reason you want to roll your own,
you face three challenges around the FULL flag:
You must detect FULL fast enough, within a 3 ns period.
And you must release FULL in response to a read clock, without getting
into metastable problems.
And you must compare the two counters without decoding glitches.
All this is stuff the we core designers have solved already for you,
at much higher speed...
Peter Alfke, Xilinx
Would it be valid to say that if the user doesn't need a(n almost)
full flag on the read side or an (almost) empty flag on the write side
that a FIFO design would be pretty relaxed?
It's often preferred to have flags act as fast as possible in the
"other" clock domain such that adding an extra clock cycle or more in
the read domain after a write or vice-versa isn't an acceptable
solution. I've been able to have my systems work well without this
stressful need.
Or is there more of a nuance that I haven't yet understood?
I appreciate your guidance,
- John_H
P
Peter Alfke
Guest
On Mar 18, 8:38 am, John_H <newsgr...@johnhandwork.com> wrote:
a "hard" FIFO), is that it has to be universal: run at 550 MHz, stop
on FULL and EMPTY, have fully programmable ALMOST flags. That requires
both binary and Gray counters, and very fast decoders, plus some
metastable protection.
A more limited design is obviously simpler.
No programmable ALMOST flags = no need for binary counters.
"Only 320 MHz" = ever so slightly relaxed timing.
But with no ALMOST flags, the write or read must be stopped in one
clock cycle !
Most users (have to and will) accept an extra delay in the release of
FULL or EMPTY, as a protection against metastability confusion.
The depth of a FIFO is irrelevant, as long as it is deep enough.
Dual-ported RAMs are a great help for the designer.
You can imagine that (after the Virtex-4 FIFO experience) we tested
the hell out of the Virtex-5 hard FIFO. We ran it for weeks with two
asynchronous clocks of several hundred MHz, just dancing around EMPTY.
No error in E14 "going empty" operations... It's a solid design.
Peter Alfke, Xilinx
Hi John,the problem we faced when designing a generic core (in my caseOn Mar 17, 10:36 pm, Peter Alfke <al...@sbcglobal.net> wrote:
If for some (strange) reason you want to roll your own,
you face three challenges around the FULL flag:
You must detect FULL fast enough, within a 3 ns period.
And you must release FULL in response to a read clock, without getting
into metastable problems.
And you must compare the two counters without decoding glitches.
All this is stuff the we core designers have solved already for you,
at much higher speed...
Peter Alfke, Xilinx
Peter,
Would it be valid to say that if the user doesn't need a(n almost)
full flag on the read side or an (almost) empty flag on the write side
that a FIFO design would be pretty relaxed?
It's often preferred to have flags act as fast as possible in the
"other" clock domain such that adding an extra clock cycle or more in
the read domain after a write or vice-versa isn't an acceptable
solution. I've been able to have my systems work well without this
stressful need.
Or is there more of a nuance that I haven't yet understood?
I appreciate your guidance,
- John_H
a "hard" FIFO), is that it has to be universal: run at 550 MHz, stop
on FULL and EMPTY, have fully programmable ALMOST flags. That requires
both binary and Gray counters, and very fast decoders, plus some
metastable protection.
A more limited design is obviously simpler.
No programmable ALMOST flags = no need for binary counters.
"Only 320 MHz" = ever so slightly relaxed timing.
But with no ALMOST flags, the write or read must be stopped in one
clock cycle !
Most users (have to and will) accept an extra delay in the release of
FULL or EMPTY, as a protection against metastability confusion.
The depth of a FIFO is irrelevant, as long as it is deep enough.
Dual-ported RAMs are a great help for the designer.
You can imagine that (after the Virtex-4 FIFO experience) we tested
the hell out of the Virtex-5 hard FIFO. We ran it for weeks with two
asynchronous clocks of several hundred MHz, just dancing around EMPTY.
No error in E14 "going empty" operations... It's a solid design.
Peter Alfke, Xilinx