Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarApr2017

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search

Messages from 92225

Article: 92225
Subject: Re: FPGA and metastability once again
From: v_mirgorodsky@yahoo.com
Date: 24 Nov 2005 01:08:19 -0800
Links: << >>  << T >>  << A >>
Hello Avrum,

Our design is very simple. We have a register where the actual data is
stored; we have a strobe register, which assert only one cycle later
after the main command register has been filled with valid information.
This way data is always stable at the command register at least one
full period of 125MHz clock cycle. Than the value of strobe latched by
another metastable trigger, whose clock is 166MHz. The system does not
transition to any state until it sees the strobe in its 166MHz clock
domain. All other stuff is really simple. We just generate couple
clears for both strobe registers and couple enables for both domains
data registers. Since we transfer only commands across the clock
boundary, we don't need very high throughput, although the design is
able to transfer a word of data across the clock boundary every three
clock cycles of slower clock.

If we miss a strobe this clock cycle, we will recognize it later. Our
system can easily tolerate that since we have a command pipeline and we
don't need to supply a new command very frequently.

This whole system depends on assumption that trigger can not have
metastable (intermediate) voltage level at its output, when its input
violates either setup or hold times or both. I heard that ancient
discrete triggers had that problem. They may generate intermediate
voltage levels on their outputs when their input voltage level is
intermediate and I am curious if this still the case for modern FPGA.

With best regards,
Vladimir S. Mirgorodsky


Avrum wrote:
> Since you haven't posted any details about how you are doing the clock
> crossing, we can't say if the system is robust or not. Dealing with clock
> crossing is a tricky issue, not just in terms of dealing with metastability,
> but also in terms of how to ensure that data is not missed, replicated, or
> otherwise mangled. 40 hours of testing is relatively short when you are
> dealing with metastability; all you have demonstrated is that your MTBF is
> not substantially less than 40hrs; it is certainly possible that you could
> have a system that works most of the time, but still fails once per day,
> once per week, once per year...
>
> Clock crossing through a FIFO is a mechanism that is well understood, and
> can be designed to be reliable in spite of metastability issues. Other
> mechanisms certainly exist, and, depending on the frequencies involved, can
> be implemented with less logic than a FIFO. However from 125MHz to 166MHz,
> many of the "easy" robust mechanisms won't work; a FIFO is your best bet.
>
> It is understandable that you don't want to "waste" block RAMs for the clock
> crossing. However, one nice features of the Xilinx architecture is the
> availability of distributed RAMs. It is relatively "cheap" to use these dual
> ported RAMs to build 16 word deep FIFOs (in any width), which are enough for
> most clock crossing applications.
>
> Avrum
>
>
> <v_mirgorodsky@yahoo.com> wrote in message
> news:1132738682.392066.268630@g14g2000cwa.googlegroups.com...
> > Hello ALL,
> >
> > I have a design with two global clocks. I have data I need to transfer
> > from one clock domain to another. I am aware of existence of FIFO
> > blocks :), but it seems to be too expensive to spend a block-ram and
> > other resources for every boundary crossing. To avoid using FIFO blocks
> > we created a handshake schematic, based on some triggers and small FSM.
> > This solution is proven to work in hardware error-free for almost 40
> > hours. First domain clock frequency is 25MHz or 125MHz (depending on
> > mode); second domain clock frequency is 166MHz.
> >
> > Naturally, some triggers in out design are metastable. Is it possible
> > to get some intermediate voltage level at the output of trigger in FPGA
> > if input signal on its Data input violates setup or hold times? In my
> > design I assume I don't get any intermediate level voltages at the
> > trigger outputs. What about signal I input into FPGA from outside? Is
> > it possible to get some intermediate voltage levels on the trigger
> > outputs by violating setup-hold times and/or IO standard voltage
> > levels?
> >
> > With best regards,
> > Vladimir S. Mirgorodsky
> >


Article: 92226
Subject: Re: Patient Monitors: Reading RS232 output w/ an FPGA
From: Mark <markebden@hotmail.com>
Date: Thu, 24 Nov 2005 01:41:46 -0800
Links: << >>  << T >>  << A >>
Thank you all for your replies. The DataCaptor software sends and receives commands, and receives data, in a server-client setup. The idea of using a microcontroller is a good one, thank you Kolja. The other sections of our circuitry are amenable to this as well: some mathematical calculations, a decoder for a 7-segment display, and (perhaps) interfacing to a LAN. Perfect. No FPGA required!

Mike: Was there a certain aspect of that document I should be looking at? (We have FDA approval for the current version, and hence, in Figure 1, have come full circle to left-most arrow pointing up.)

Best regards,

Mark

Article: 92227
Subject: Re: Case expression?
From: "john Doef" <john_doef@yahoo.com>
Date: 24 Nov 2005 02:20:35 -0800
Links: << >>  << T >>  << A >>

Jonathan Bromley a =E9crit :
[=2E..]
>
> Probably the nicest way is to declare a subtype - you can do this
> locally in the process, so it doesn't pollute the architecture.
> Then type-qualify the expression:
>
> process (...)
>   [other declarations]
>   subtype SLV3 is std_logic_vector(2 downto 0);
> begin
>   ...
>   CASE SLV3'(bit1 & bit2 & bit3) IS
>     ...
>
> Note the apostrophe between subtype name and
> opening parenthesis.
>
> Depending on the application, you may be able to think of
> a more apt name for the subtype.
Be *very* careful when you use type-qualified expressions.  Indeed, the
expression type
must be the same as the type name.  If this is not the case (like
here), a fully vhdl LRM compliant simulator should detect an error
here.

Therefore, you'd better to use a type conversion:
 SLV3 (bit1 & bit2 & bit3)

JD.


Article: 92228
Subject: case statement fault
From: "Marco" <marco@marylon.com>
Date: 24 Nov 2005 02:35:25 -0800
Links: << >>  << T >>  << A >>
Starting from the ISE quick up/down 4bit counter tutorial, I inserted a
case statement to handle a single digit 7-segment display, but keep on
getting a parse error on the last line of the statement and don't know
why.

entity counter is
    Port ( clock : in std_logic;
           direction : in std_logic;
           count_out : out std_logic_vector(3 downto 0);
			  display7_out: out std_logic_vector(6 downto 0));
end counter;

architecture Behavioral of counter is

	signal count_int : std_logic_vector(3 downto 0) := "0000";
  	signal display7 : std_logic_vector(6 downto 0);

begin

process (clock)
begin

if clock ='1' and clock'event then

	if direction = '1' then
     	    count_int <= count_int + 1;
     	else
   	    count_int <= count_int - 1;
     	 end if;

	case count_int is
	when "0000" =>			-- Indicazione "0"			display7 <= "0111111";
	when "0001" =>			-- Indicazione "1"
	display7 <= "0000110";
	when "0010" =>			-- Indicazione "2"
	display7 <= "1011011";
	when "0011" =>			-- Indicazione "3"
               display7 <= "1001111";
	when "0100" =>			-- Indicazione "4"
	display7 <= "1100110";
	when "0101" =>			-- Indicazione "5"
	display7 <= "1101101";
	when "0110" =>			-- Indicazione "6"
	display7 <= "1111100";
	when "0111" =>			-- Indicazione "7"
                display7 <= "0000111";
	when "1000" =>			-- Indicazione "8"
	display7 <= "1111111";
	when "1001" =>			-- Indicazione "9"
	display7 <= "1100111";
                when "1010" =>			-- Indicazione "A"
	display7 <= "1110111";
	when "1011" =>			-- Indicazione "b"
	display7 <= "1111100";
	when "1100" =>			-- Indicazione "C"
	display7 <= "0111001";
	when "1101" =>			-- Indicazione "d"
                display7 <= "1011110";
	when "1110" =>			-- Indicazione "e"
	display7 <= "1111011";
	when "1111" =>			-- Indicazione "F"
	display7 <= "1110001";
	when others =>			-- Indicazione "E" -> fault
	display7 => "1111001";                              -- HERE SHOULD BE
THE PARSE ERROR ACCORDING TO XST
	end case;

end if;

end process;

display7_out <= display7;
count_out <= count_int;

end Behavioral;


When I check syntax with XST I get "HDLParsers:164 <path> Line 89.
parse error, unexpected ROW, expecting OPENPAR or TICK or LSQBRACK".
It seems I'm wrong with my CASE statement, but where?
Thanks, Marco


Article: 92229
Subject: Re: Wishbone comments
From: "Jon Beniston" <jon@beniston.com>
Date: 24 Nov 2005 03:10:24 -0800
Links: << >>  << T >>  << A >>
>  What SoC interconnect are you using? 

AMBA AXI.

Cheers,
Jon


Article: 92230
Subject: Memory in VHDL
From: "Martin Schoeberl" <mschoebe@mail.tuwien.ac.at>
Date: Thu, 24 Nov 2005 13:07:48 +0100
Links: << >>  << T >>  << A >>
I would like to code the on-chip memory in vendor neutral VHDL.
I got it running for a dual-port memory with single clock and
same port sizes for the read and write port.

However, I need a memory with a 32-bit write port and an 8-bit
read port. So far I was not able to code it in VHDL in a way
that the Synthesizer inferres the correct block ram without
an extra read MUX.

BTW: I do my test at the moment with Quartus. Will see how
Xilinx XSE will support this.

Martin 



Article: 92231
Subject: Re: case statement fault
From: Tim Good <elp04trg@sheffield.ac.uk>
Date: Thu, 24 Nov 2005 13:39:20 +0000
Links: << >>  << T >>  << A >>
Hi Marco,

Try
when others =>	
	display7 <= "1111001";  -- use <= for assignment not =>

I know you new this one really ;-)

Enjoy

Tim



Marco wrote:
> Starting from the ISE quick up/down 4bit counter tutorial, I inserted a
> case statement to handle a single digit 7-segment display, but keep on
> getting a parse error on the last line of the statement and don't know
> why.
> 
> entity counter is
>     Port ( clock : in std_logic;
>            direction : in std_logic;
>            count_out : out std_logic_vector(3 downto 0);
> 			  display7_out: out std_logic_vector(6 downto 0));
> end counter;
> 
> architecture Behavioral of counter is
> 
> 	signal count_int : std_logic_vector(3 downto 0) := "0000";
>   	signal display7 : std_logic_vector(6 downto 0);
> 
> begin
> 
> process (clock)
> begin
> 
> if clock ='1' and clock'event then
> 
> 	if direction = '1' then
>      	    count_int <= count_int + 1;
>      	else
>    	    count_int <= count_int - 1;
>      	 end if;
> 
> 	case count_int is
> 	when "0000" =>			-- Indicazione "0"			display7 <= "0111111";
> 	when "0001" =>			-- Indicazione "1"
> 	display7 <= "0000110";
> 	when "0010" =>			-- Indicazione "2"
> 	display7 <= "1011011";
> 	when "0011" =>			-- Indicazione "3"
>                display7 <= "1001111";
> 	when "0100" =>			-- Indicazione "4"
> 	display7 <= "1100110";
> 	when "0101" =>			-- Indicazione "5"
> 	display7 <= "1101101";
> 	when "0110" =>			-- Indicazione "6"
> 	display7 <= "1111100";
> 	when "0111" =>			-- Indicazione "7"
>                 display7 <= "0000111";
> 	when "1000" =>			-- Indicazione "8"
> 	display7 <= "1111111";
> 	when "1001" =>			-- Indicazione "9"
> 	display7 <= "1100111";
>                 when "1010" =>			-- Indicazione "A"
> 	display7 <= "1110111";
> 	when "1011" =>			-- Indicazione "b"
> 	display7 <= "1111100";
> 	when "1100" =>			-- Indicazione "C"
> 	display7 <= "0111001";
> 	when "1101" =>			-- Indicazione "d"
>                 display7 <= "1011110";
> 	when "1110" =>			-- Indicazione "e"
> 	display7 <= "1111011";
> 	when "1111" =>			-- Indicazione "F"
> 	display7 <= "1110001";
> 	when others =>			-- Indicazione "E" -> fault
> 	display7 => "1111001";                              -- HERE SHOULD BE
> THE PARSE ERROR ACCORDING TO XST
> 	end case;
> 
> end if;
> 
> end process;
> 
> display7_out <= display7;
> count_out <= count_int;
> 
> end Behavioral;
> 
> 
> When I check syntax with XST I get "HDLParsers:164 <path> Line 89.
> parse error, unexpected ROW, expecting OPENPAR or TICK or LSQBRACK".
> It seems I'm wrong with my CASE statement, but where?
> Thanks, Marco
> 

Article: 92232
Subject: Re: FPGA and metastability once again
From: "Avrum" <noasvpraumm@nospamsympatico.ca>
Date: Thu, 24 Nov 2005 08:46:59 -0500
Links: << >>  << T >>  << A >>
It sounds like what you have is workable; the key is the relatively low
throughput through the clock crossing.

However, you do have to worry about metastability and its effects in a
system like this.

What I would do is enable the strobe on the 125MHz domain on the same clock
that the command is loaded into the flops on the 125MHz domain. Then bring
this strobe across to the 166MHz domain using TWO flip flops back to back
with a constraint on the wire between the Q of the first and the D of the
second. This constraint should artificially constrain the propagation delay
between these two points to be significantly less than the 6ns clock period
of the 166MHz clock; say 2ns to give 4ns for metastability resolution (as
Peter was talking about).

Then you can use this signal to enable the FFs on the 166MHz domain to
sample the data being held in the FFs on the 125MHz domain.

If the data is guaranteed to be stable in the 125MHz domain for "long
enough" (enough to get the strobe synchronized into the 166MHz domain and
the data latched), then you don't necessarily need a handshake mechanism
back to the 125MHz domain; you can edge detect the strobe in the 166MHz
domain and only load the 166MHz FFs on the first clock when the strobe is
high.

If you do need to handshake back to the 125MHz domain, then you will need to
the same thing in the opposite direction; double synchronize the strobe
going back and place a constraint on the wire between the two flops.
Remember, that a pulse on the 166MHz is not guaranteed to be seen in the
125MHz domain; in general, you can only catch a pulse in a different clock
domain if the period of your source clock is larger (and I would say
significantly larger) than the period of your destination clock plus the
setup time and the hold time of the flip flop on the destination domain. If
this is not the case, then you can stretch the pulse in the source domain to
cover more than one clock period. However, if you do this, you must do it so
that the stretched pulse is the output of a flipflop, and not (say) the
output of any combinational gate.

With all the synchronizing required, I expect that the throughput of this
system will be somewhat less than one command every three clocks in the
125MHz domain. If you can tolerate the slower throughput, then this will
work. If not, then you will have to use a FIFO!

Avrum


<v_mirgorodsky@yahoo.com> wrote in message
news:1132823299.349982.285350@f14g2000cwb.googlegroups.com...
> Hello Avrum,
>
> Our design is very simple. We have a register where the actual data is
> stored; we have a strobe register, which assert only one cycle later
> after the main command register has been filled with valid information.
> This way data is always stable at the command register at least one
> full period of 125MHz clock cycle. Than the value of strobe latched by
> another metastable trigger, whose clock is 166MHz. The system does not
> transition to any state until it sees the strobe in its 166MHz clock
> domain. All other stuff is really simple. We just generate couple
> clears for both strobe registers and couple enables for both domains
> data registers. Since we transfer only commands across the clock
> boundary, we don't need very high throughput, although the design is
> able to transfer a word of data across the clock boundary every three
> clock cycles of slower clock.
>
> If we miss a strobe this clock cycle, we will recognize it later. Our
> system can easily tolerate that since we have a command pipeline and we
> don't need to supply a new command very frequently.
>
> This whole system depends on assumption that trigger can not have
> metastable (intermediate) voltage level at its output, when its input
> violates either setup or hold times or both. I heard that ancient
> discrete triggers had that problem. They may generate intermediate
> voltage levels on their outputs when their input voltage level is
> intermediate and I am curious if this still the case for modern FPGA.
>
> With best regards,
> Vladimir S. Mirgorodsky
>
>
> Avrum wrote:
> > Since you haven't posted any details about how you are doing the clock
> > crossing, we can't say if the system is robust or not. Dealing with
clock
> > crossing is a tricky issue, not just in terms of dealing with
metastability,
> > but also in terms of how to ensure that data is not missed, replicated,
or
> > otherwise mangled. 40 hours of testing is relatively short when you are
> > dealing with metastability; all you have demonstrated is that your MTBF
is
> > not substantially less than 40hrs; it is certainly possible that you
could
> > have a system that works most of the time, but still fails once per day,
> > once per week, once per year...
> >
> > Clock crossing through a FIFO is a mechanism that is well understood,
and
> > can be designed to be reliable in spite of metastability issues. Other
> > mechanisms certainly exist, and, depending on the frequencies involved,
can
> > be implemented with less logic than a FIFO. However from 125MHz to
166MHz,
> > many of the "easy" robust mechanisms won't work; a FIFO is your best
bet.
> >
> > It is understandable that you don't want to "waste" block RAMs for the
clock
> > crossing. However, one nice features of the Xilinx architecture is the
> > availability of distributed RAMs. It is relatively "cheap" to use these
dual
> > ported RAMs to build 16 word deep FIFOs (in any width), which are enough
for
> > most clock crossing applications.
> >
> > Avrum
> >
> >
> > <v_mirgorodsky@yahoo.com> wrote in message
> > news:1132738682.392066.268630@g14g2000cwa.googlegroups.com...
> > > Hello ALL,
> > >
> > > I have a design with two global clocks. I have data I need to transfer
> > > from one clock domain to another. I am aware of existence of FIFO
> > > blocks :), but it seems to be too expensive to spend a block-ram and
> > > other resources for every boundary crossing. To avoid using FIFO
blocks
> > > we created a handshake schematic, based on some triggers and small
FSM.
> > > This solution is proven to work in hardware error-free for almost 40
> > > hours. First domain clock frequency is 25MHz or 125MHz (depending on
> > > mode); second domain clock frequency is 166MHz.
> > >
> > > Naturally, some triggers in out design are metastable. Is it possible
> > > to get some intermediate voltage level at the output of trigger in
FPGA
> > > if input signal on its Data input violates setup or hold times? In my
> > > design I assume I don't get any intermediate level voltages at the
> > > trigger outputs. What about signal I input into FPGA from outside? Is
> > > it possible to get some intermediate voltage levels on the trigger
> > > outputs by violating setup-hold times and/or IO standard voltage
> > > levels?
> > >
> > > With best regards,
> > > Vladimir S. Mirgorodsky
> > >
>



Article: 92233
Subject: Re: Memory in VHDL
From: "Martin Schoeberl" <mschoebe@mail.tuwien.ac.at>
Date: Thu, 24 Nov 2005 15:24:14 +0100
Links: << >>  << T >>  << A >>
>I would like to code the on-chip memory in vendor neutral VHDL.
> I got it running for a dual-port memory with single clock and
> same port sizes for the read and write port.
>
> However, I need a memory with a 32-bit write port and an 8-bit
> read port. So far I was not able to code it in VHDL in a way
> that the Synthesizer inferres the correct block ram without
> an extra read MUX.
>

I'll give up one this vendor independent block RAM project. For
the 32-bit write data, 8-bit read data with registered address,
in data and unregistered out data RAM coded in VHDL I got:

On the Altera Cyclone: generates a 32-bit dual port RAM with an
external 4:1 MUX. This MUX hurts fmax (from 94MHz down to 84MHz)!

On the Xlinix Spartan-3: The RAM gets implemented as distributed
RAM! Uses a lot of LCs and the fmax goes from 65MHz down to
50MHz

So I will bite the bullet and use two vendor specific VHDL files.
However, there is one open issue: I want the memory size be
configurable via a generic. This is possible with Alteras
altsyncram.

For Xilinx I only know those RAMB16_S9_S36 components where
the memory size is part of the component name. Is there a
a Xilinx block RAM component where I can specify the size?

Thanks,
Martin 



Article: 92234
Subject: Re: Memory in VHDL
From: "John Adair" <removethisthenleavejea@replacewithcompanyname.co.uk>
Date: Thu, 24 Nov 2005 14:41:45 -0000
Links: << >>  << T >>  << A >>
The RAMB16 elements are the raw RAM macros. The Sx part of the name 
indicates the port width. You can build up bigger memories in Coregen which 
is a bit like the Altera Megawizard tool or build them up yourself using 
generic statements using the raw macros.

If you looking at switching between vendors one trick is to hide a RAM 
inside a wrapper file. If you use the wrapper level as the RAM component for 
instantiation then you will only have to change the technology based  memory 
element in one place i.e. the the wrapper file.

Some synthesisers are capable of inferring RAM usually using an indexed 
array of something like VHDL's "std_logic_vector". I can't tell you much 
about the results as it isn't my own preferred method but a non-vendor 
synthesiser may do better than one offered by the silicon vendors.

John Adair
Enterpoint Ltd. - Home of FPGA PCI Development Boards.
http://www.enterpoint.co.uk


"Martin Schoeberl" <mschoebe@mail.tuwien.ac.at> wrote in message 
news:4385cd12$0$8024$3b214f66@tunews.univie.ac.at...
> >I would like to code the on-chip memory in vendor neutral VHDL.
>> I got it running for a dual-port memory with single clock and
>> same port sizes for the read and write port.
>>
>> However, I need a memory with a 32-bit write port and an 8-bit
>> read port. So far I was not able to code it in VHDL in a way
>> that the Synthesizer inferres the correct block ram without
>> an extra read MUX.
>>
>
> I'll give up one this vendor independent block RAM project. For
> the 32-bit write data, 8-bit read data with registered address,
> in data and unregistered out data RAM coded in VHDL I got:
>
> On the Altera Cyclone: generates a 32-bit dual port RAM with an
> external 4:1 MUX. This MUX hurts fmax (from 94MHz down to 84MHz)!
>
> On the Xlinix Spartan-3: The RAM gets implemented as distributed
> RAM! Uses a lot of LCs and the fmax goes from 65MHz down to
> 50MHz
>
> So I will bite the bullet and use two vendor specific VHDL files.
> However, there is one open issue: I want the memory size be
> configurable via a generic. This is possible with Alteras
> altsyncram.
>
> For Xilinx I only know those RAMB16_S9_S36 components where
> the memory size is part of the component name. Is there a
> a Xilinx block RAM component where I can specify the size?
>
> Thanks,
> Martin
> 



Article: 92235
Subject: Re: Memory in VHDL
From: Aurelian Lazarut <aurash@xilinx.com>
Date: Thu, 24 Nov 2005 14:42:30 +0000
Links: << >>  << T >>  << A >>
Martin Schoeberl wrote:

>>I would like to code the on-chip memory in vendor neutral VHDL.
>>I got it running for a dual-port memory with single clock and
>>same port sizes for the read and write port.
>>
>>However, I need a memory with a 32-bit write port and an 8-bit
>>read port. So far I was not able to code it in VHDL in a way
>>that the Synthesizer inferres the correct block ram without
>>an extra read MUX.
>>
>>    
>>
>
>I'll give up one this vendor independent block RAM project. For
>the 32-bit write data, 8-bit read data with registered address,
>in data and unregistered out data RAM coded in VHDL I got:
>
>On the Altera Cyclone: generates a 32-bit dual port RAM with an
>external 4:1 MUX. This MUX hurts fmax (from 94MHz down to 84MHz)!
>
>On the Xlinix Spartan-3: The RAM gets implemented as distributed
>RAM! Uses a lot of LCs and the fmax goes from 65MHz down to
>50MHz
>
>So I will bite the bullet and use two vendor specific VHDL files.
>However, there is one open issue: I want the memory size be
>configurable via a generic. This is possible with Alteras
>altsyncram.
>
>For Xilinx I only know those RAMB16_S9_S36 components where
>the memory size is part of the component name. Is there a
>a Xilinx block RAM component where I can specify the size?
>  
>
NO, but you can use GENERATE (assuming VHDL) to switch between different 
bram geometries
Aurelian

>Thanks,
>Martin 
>
>
>  
>


-- 
 __
/ /\/\ Aurelian Lazarut
\ \  / System Verification Engineer
/ /  \ Xilinx Ireland
\_\/\/
 
phone:	353 01 4032639
fax:	353 01 4640324
    
     

Article: 92236
Subject: Re: XC2000
From: mstrug <>
Date: Thu, 24 Nov 2005 07:07:56 -0800
Links: << >>  << T >>  << A >>
Yes, I had a reason for using XC2000 device. I'm from Poland and here there is no way to buy any of Xilinx FPGA device, even if I found in some Internet shop in Poland FPGA, it is too expensive. Buying FPGA in shop in foreign countries where FPGA are chip, price of shipping to Poland is also too high. I have two XC2064 and I want use it to build FIFO dedicated driver for SRAMs memory. I know that it could be builded in this device because I have old PC/104 single board computer which has FIFO driver in XC2064.

If there is no way to get old XACT software, I probably buy CPLD from Atmel because its price is very less than Xilinx CPLD (in Poland). But on the other hand the software from Atmel for his CPLD is realy poor (in front of Xilinx Webpack). Meybe I design my device in webpack and then convert it to the atmel device. This will be probably the most economical solution for me.

Article: 92237
Subject: Re: Xilinx DCM_ADV 280MHz no lock
From: "Jochen" <JFrensch@HarmanBecker.com>
Date: 24 Nov 2005 07:18:12 -0800
Links: << >>  << T >>  << A >>

Brad Smallridge wrote:
> Hi,
>
> this task, one using the FX output to go from 40 to 140 MHz (7/2), and
> another DCM using 2X output to go from 140 to 280.  The FX output locks OK
> and the divided output looks OK on the scope.  The 2X lock output seems to
> lock intermitently, trying to get to high, and the 2X divided output is
> "fuzzy".

ds099 for Spartan3 / jitter-calculator for Virtex2:
The FX-output of first DCM's output will have a worst-case-jitter of
740ps
(http://www.xilinx.com/applications/web_ds_v2/jitter_calc.htm)
whereas only 300ps are allowed for CLKIN of 2nd DCM's input !

Cheers
Jochen


Article: 92238
Subject: Re: Access to long lines in Virtex-II
From: Javier Castillo <javier.castillo@urjc.es>
Date: Thu, 24 Nov 2005 16:23:55 +0100
Links: << >>  << T >>  << A >>
On 22 Nov 2005 18:39:50 -0800, heiko@csse.uwa.edu.au wrote:

>Hi,
>can someone tell me where I can access (read/write) the horizontal long
>lines in the Virtex-II architecture. In the FPGA editor the long lines
>are connected to blocks on either ends of the FPGA and they are
>connected to the switch boxes of the CLBs. However, when implementing
>small designs the routing tools seem to drive the long lines only from
>the ends. Can they be driven and read from each CLB, too?
>Regards
>Heiko

You can access them thorugh the TBUFs

Javier

Article: 92239
Subject: Re: case statement fault
From: "Marco" <marco@marylon.com>
Date: 24 Nov 2005 07:26:36 -0800
Links: << >>  << T >>  << A >>
Thanks Tim, it works now, I was not drunk, but I did not see it!
Marco


Article: 92240
Subject: Re: Case expression?
From: Jonathan Bromley <jonathan.bromley@doulos.com>
Date: Thu, 24 Nov 2005 15:27:37 +0000
Links: << >>  << T >>  << A >>
On 24 Nov 2005 02:20:35 -0800, "john Doef" 
<john_doef@yahoo.com> wrote:

>> process (...)
>>   [other declarations]
>>   subtype SLV3 is std_logic_vector(2 downto 0);
>> begin
>>   ...
>>   CASE SLV3'(bit1 & bit2 & bit3) IS

>Be *very* careful when you use type-qualified expressions.  Indeed, the
>expression type must be the same as the type name.  If this is
> not the case (like here)

Can you explain?  I can't see why a concatenation of three
std_logic is incompatible with my definition of SLV3.

Of course you are correct that the expression must admit of
interpretation as the qualifying type, but in this case I think
it's OK.  I'm happy to be proved wrong if you can cite the 
appropriate bit of the LRM, though.
-- 
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.

Article: 92241
Subject: Re: Case expression?
From: "john Doef" <john_doef@yahoo.com>
Date: 24 Nov 2005 07:40:24 -0800
Links: << >>  << T >>  << A >>

Jonathan Bromley a =E9crit :

> On 24 Nov 2005 02:20:35 -0800, "john Doef"
> <john_doef@yahoo.com> wrote:
>
> >> process (...)
> >>   [other declarations]
> >>   subtype SLV3 is std_logic_vector(2 downto 0);
> >> begin
> >>   ...
> >>   CASE SLV3'(bit1 & bit2 & bit3) IS
>
> >Be *very* careful when you use type-qualified expressions.  Indeed, the
> >expression type must be the same as the type name.  If this is
> > not the case (like here)
>
> Can you explain?  I can't see why a concatenation of three
> std_logic is incompatible with my definition of SLV3.
>
> Of course you are correct that the expression must admit of
> interpretation as the qualifying type, but in this case I think
> it's OK.  I'm happy to be proved wrong if you can cite the
> appropriate bit of the LRM, though.
This problem has been discussed in:
www.eda.org/vasg/VHDL98RevD.pdf

See LCS2 (page 5).

Basically, subtype of (bit1 & bit2 & bit3) is std_logic_vector (0 to
2), which is
*not* the same as your SLV3!

JD.


Article: 92242
Subject: simulating code loading in memory and jumping to memory
From: "sjulhes" <t@aol.fr>
Date: Thu, 24 Nov 2005 17:00:32 +0100
Links: << >>  << T >>  << A >>
Hi,

I use EDK/ISE/Modelsim.
Just want to make some tests and learn on this subject, i would like to
create a small system like :
microblaze
external sdram or ddr
uart.

The code I will have is to loop on a xil_printf of hello world on the UART.

So I will generate an elf file to do this.

Secondly, I will write some kind of bootloader in BRAM that will read the
elf file under modelsim and write it into the Sdram or ddr.
Once it is done, I'll jump program to external sdram/ddr  to have hello
world running.

What would be the best way to read the .elf file during simulation and write
it to opb/plb sdram/ddr ???
Then what is the best way to jump from internal BRAM execution to external
sdram execution ?

Thanks for your help.




Article: 92243
Subject: Re: Memory in VHDL
From: "Martin Schoeberl" <mschoebe@mail.tuwien.ac.at>
Date: Thu, 24 Nov 2005 18:11:52 +0100
Links: << >>  << T >>  << A >>
> The RAMB16 elements are the raw RAM macros. The Sx part of the name indicates the port width. You can build up bigger memories in 
> Coregen which is a bit like the Altera Megawizard tool or build them up yourself using generic statements using the raw macros.

Can you describe this a little bit more specific, please? Are the
other components available to describe Xilinx block RAMs?

BTW: With the web edition I don't have Coregen and I also don't
use the Megawizzard in Quartus. Ideal setup is a single generic
parameter with the memory size (in lenght of the address).

> If you looking at switching between vendors one trick is to hide a RAM inside a wrapper file. If you use the wrapper level as the 
> RAM component for instantiation then you will only have to change the technology based  memory element in one place i.e. the the 
> wrapper file.

That's the way I do it. I switch between technologies with different
files in the project. I also use this different VHDL files in projects
for other customization - primitiv, but efficient.


> Some synthesisers are capable of inferring RAM usually using an indexed array of something like VHDL's "std_logic_vector". I can't 
> tell you much about the results as it isn't my own preferred method but a non-vendor synthesiser may do better than one offered by 
> the silicon vendors.

The Xilinx tool interffered distributed RAM from the VHDL description.
A thing I definitely don't want. Quartus had problems with the
different port sizes, but single port sizes work very well.

Martin


>> >I would like to code the on-chip memory in vendor neutral VHDL.
>>> I got it running for a dual-port memory with single clock and
>>> same port sizes for the read and write port.
>>>
>>> However, I need a memory with a 32-bit write port and an 8-bit
>>> read port. So far I was not able to code it in VHDL in a way
>>> that the Synthesizer inferres the correct block ram without
>>> an extra read MUX.
>>>
>>
>> I'll give up one this vendor independent block RAM project. For
>> the 32-bit write data, 8-bit read data with registered address,
>> in data and unregistered out data RAM coded in VHDL I got:
>>
>> On the Altera Cyclone: generates a 32-bit dual port RAM with an
>> external 4:1 MUX. This MUX hurts fmax (from 94MHz down to 84MHz)!
>>
>> On the Xlinix Spartan-3: The RAM gets implemented as distributed
>> RAM! Uses a lot of LCs and the fmax goes from 65MHz down to
>> 50MHz
>>
>> So I will bite the bullet and use two vendor specific VHDL files.
>> However, there is one open issue: I want the memory size be
>> configurable via a generic. This is possible with Alteras
>> altsyncram.
>>
>> For Xilinx I only know those RAMB16_S9_S36 components where
>> the memory size is part of the component name. Is there a
>> a Xilinx block RAM component where I can specify the size?
>>
>> Thanks,
>> Martin
>>
>
> 



Article: 92244
Subject: Re: Memory in VHDL
From: "Martin Schoeberl" <mschoebe@mail.tuwien.ac.at>
Date: Thu, 24 Nov 2005 18:14:56 +0100
Links: << >>  << T >>  << A >>
>>
>>For Xilinx I only know those RAMB16_S9_S36 components where
>>the memory size is part of the component name. Is there a
>>a Xilinx block RAM component where I can specify the size?
>>
> NO, but you can use GENERATE (assuming VHDL) to switch between different bram geometries
> Aurelian
>
Really, that's it? Not very comfortable - a plus for Quartus.

Perhaps one in this group has already done this coding effort
and can provide the VHDL file?

Martin 



Article: 92245
Subject: Re: XC2000
From: "Peter Alfke" <alfke@sbcglobal.net>
Date: 24 Nov 2005 09:28:51 -0800
Links: << >>  << T >>  << A >>
Please explain what makes Poland so expensive. (I have spent some time
there). The Iron Curtain is long gone. PL is part of the EU, postal
rates from the US are reasonable. It is not a rich country, but people
are not poor. Why would you spend days (weeks?) of chasing obsolete
software and an old computer to program your tiny and slow part, when
you can avoid all that by using the smallest and cheapst modern FPGA,
like a Spartan3 device. You seem to believe that you have a reason...
Peter Alfke


Article: 92246
Subject: Re: Memory in VHDL
From: Olaf Petzold <olaf@mdcc-fun.net>
Date: Thu, 24 Nov 2005 19:14:45 +0100
Links: << >>  << T >>  << A >>
Hi,

> I'll give up one this vendor independent block RAM project. For
> the 32-bit write data, 8-bit read data with registered address,

Don't give up ;-)

Maybe the code attached from my project will help you. Using 
configurations you can choose the architecture.

Regards,
Olaf


---8<---
library unisim;
use unisim.vcomponents.all;

library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;


entity ram_512x80 is

    generic (
       RESET_ACTIVE : std_logic := '1');

    port (
       clk   : in  std_logic;
       reset : in  std_logic;
       en    : in  std_logic;
       AB    : in  std_logic_vector(8 downto 0);
       DB_I  : in  std_logic_vector(79 downto 0);
       DB_O  : out std_logic_vector(79 downto 0);
       we    : in  std_logic);

end entity ram_512x80;

-------------------------------------------------------------------------------

architecture banking of ram_512x80 is

    constant NUM_BLOCKS : positive := 10;  -- XC2S100

    signal m_clk   : std_logic;
    signal m_reset : std_logic;

begin

    -- reset conversation
    m_reset <= '1' when (reset = RESET_ACTIVE) else '0';

    -- xilinx specific
    clk_buf : BUFG
       port map (I => clk, O => m_clk);

    -- instance block ram
    bram : for n in NUM_BLOCKS-1 downto 0 generate

       function lsb (i : integer) return integer is
       begin
          return i*8;
       end;

       function msb (i : integer) return integer is
       begin
          return lsb(i) + 7;
       end;


    begin
       -- D(79:72) D(71:64) D(63:56) D(55:48) D(47:40) D(39:32) 
D(31:24) D(23:16) D(15:8) D(7:0)
       ram_i : RAMB4_S8
          -- RAMB4_S8: Virtex/E, Spartan-II/IIE 512 x 8 Single-Port RAM
          -- 
http://toolbox.xilinx.com/docsan/xilinx7/de/libs/lib/ramb4_sn.pdf
          generic map (
             INIT_00 => 
X"0000000000000000000000000000000000000000000000000000000000000000",
             INIT_01 => 
X"0000000000000000000000000000000000000000000000000000000000000000",
             INIT_02 => 
X"0000000000000000000000000000000000000000000000000000000000000000",
             INIT_03 => 
X"0000000000000000000000000000000000000000000000000000000000000000",
             INIT_04 => 
X"0000000000000000000000000000000000000000000000000000000000000000",
             INIT_05 => 
X"0000000000000000000000000000000000000000000000000000000000000000",
             INIT_06 => 
X"0000000000000000000000000000000000000000000000000000000000000000",
             INIT_07 => 
X"0000000000000000000000000000000000000000000000000000000000000000",
             INIT_08 => 
X"0000000000000000000000000000000000000000000000000000000000000000",
             INIT_09 => 
X"0000000000000000000000000000000000000000000000000000000000000000",
             INIT_0A => 
X"0000000000000000000000000000000000000000000000000000000000000000",
             INIT_0B => 
X"0000000000000000000000000000000000000000000000000000000000000000",
             INIT_0C => 
X"0000000000000000000000000000000000000000000000000000000000000000",
             INIT_0D => 
X"0000000000000000000000000000000000000000000000000000000000000000",
             INIT_0E => 
X"0000000000000000000000000000000000000000000000000000000000000000",
             INIT_0F => 
X"0000000000000000000000000000000000000000000000000000000000000000")
          port map (
             CLK  => m_clk,                       -- Clock input
             RST  => m_reset,                     -- Synchronous reset 
input
             EN   => en,                          -- RAM enable input
             ADDR => AB,                          -- 9-bit address input
             DO   => DB_O(msb(n) downto lsb(n)),  -- 8-bit data output
             DI   => DB_I(msb(n) downto lsb(n)),  -- 8-bit data input
             WE   => we);                         -- RAM write enable 
input

    end generate;


end architecture banking;


-------------------------------------------------------------------------------


architecture infering of ram_512x80 is

    constant BIT_DEPTH : positive := 512;
    constant BIT_WIDTH : positive := 80;

    type ram_t is array(BIT_DEPTH-1 downto 0)
       of std_logic_vector(BIT_WIDTH-1 downto 0);

    -- infer RAM
    signal blockram : ram_t;

begin

    -- Note, Spartan-II doesn't have "No Change Mode";
    -- Using Block RAM Single Port "Write First Mode"
    process (clk)
    begin
       if rising_edge(clk) then
          if (en = '1') then
             if (we = '1') then
                blockram(to_integer(unsigned(AB))) <= DB_I;
                DB_O <= DB_I;
             else
                DB_O <= blockram(to_integer(unsigned(AB)));
             end if;
          end if;
       end if;
    end process;

end architecture infering;

Article: 92247
Subject: Re: XC2000
From: "Antti Lukats" <antti@openchip.org>
Date: Thu, 24 Nov 2005 19:44:50 +0100
Links: << >>  << T >>  << A >>
"Peter Alfke" <alfke@sbcglobal.net> schrieb im Newsbeitrag
news:1132853331.047793.240650@z14g2000cwz.googlegroups.com...
> Please explain what makes Poland so expensive. (I have spent some time
> there). The Iron Curtain is long gone. PL is part of the EU, postal
> rates from the US are reasonable. It is not a rich country, but people
> are not poor. Why would you spend days (weeks?) of chasing obsolete
> software and an old computer to program your tiny and slow part, when
> you can avoid all that by using the smallest and cheapst modern FPGA,
> like a Spartan3 device. You seem to believe that you have a reason...
> Peter Alfke
>

Hi Peter,

you did beat me in response :)
I was actually offering to send some Spartan-2 chips that are somewhere on
my desk to the original poster.

There are different sales channels, and the overhead they may charge may
differ greatly, so I can easily belive that buying qty 1 Xilinx FPGA from
Poland is not possible without paying for the shipment more than the silicon
does cost.

to the OP, the offer is still valid, please ask in private email if you are
interested. I defenetly have some spartan-2 in TQ144 overleft

Antti

S3E development board, how low can it go?
http://xilant.com/content/view/15/51/



Article: 92248
Subject: Re: Xst optimizes almost everything away
From: Adrian Knoth <adi@thur.de>
Date: Thu, 24 Nov 2005 19:45:33 +0000 (UTC)
Links: << >>  << T >>  << A >>
Andy Peters <Bassman59a@yahoo.com> wrote:

> THINK HARDWARE.

Thanks, this was more or less the main reason.

> How would you implement the rising_edge() function?  How does the
> hardware "know" when an edge occurs?

Thanks for this explanation, I ever wondered how to do this, your
code has enlightened me.

> follows a template that the synthesis tool uses to generate hardware.
> The synthesis tool tries to match the code against standard templates
> to infer various hardware structures (flip-flops, RAMs, etc).  (It also
> works to minimize logic, etc.)

I was misled by a statement in mind "With VHDL you can design your
hardware if it was software." Unfortunately the quote originally
said "With SystemC ..." and I bet is as wrong as my version ;)

> Is this clear?

Yes. I have everything in my bitstream now. Thanks for your
help (and to all others, too).


-- 
mail: adi@thur.de  	http://adi.thur.de	PGP: v2-key via keyserver

For more information see readme-file WASN.DAT

Article: 92249
Subject: Re: Memory in VHDL
From: "Martin Schoeberl" <mschoebe@mail.tuwien.ac.at>
Date: Thu, 24 Nov 2005 20:48:54 +0100
Links: << >>  << T >>  << A >>
Hi Olaf,

>> I'll give up one this vendor independent block RAM project. For
>> the 32-bit write data, 8-bit read data with registered address,
>
> Don't give up ;-)
>
> Maybe the code attached from my project will help you. Using configurations you can choose the architecture.
>

Not so bad! The infering architecture generates a block ram
for the Spartan-3. However, with Quartus it generates registers.
A little step forward ;-)

The next step is to generate a memory with different port sizes.
The attached code instances a block ram with a MUX in Quartus
and distributed memory with the Xilinx tool.


--
--    gen_mem.vhd
--
--    VHDL memory experiments
--
--    address, data in are registered
--    data out is unregistered
--
--

library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;

entity jbc is
generic (jpc_width : integer := 10);
port (
    clk            : in std_logic;
    data           : in std_logic_vector(31 downto 0);
    rd_addr        : in std_logic_vector(jpc_width-1 downto 0);
    wr_addr        : in std_logic_vector(jpc_width-3 downto 0);
    wr_en          : in std_logic;
    q              : out std_logic_vector(7 downto 0)
);
end jbc;

--
--    registered wraddress, wren
--    registered din
--    registered rdaddress
--    unregistered dout
--
architecture rtl of jbc is

    constant nwords : integer := 2**(jpc_width-2);
    type mem is array(0 to nwords-1) of std_logic_vector(31 downto 0);
    signal ram_block: mem;

    signal d: std_logic_vector(31 downto 0);

    signal rda_reg             : std_logic_vector(jpc_width-1 downto 0);

begin

    d <= ram_block(to_integer(unsigned(rda_reg(jpc_width-1 downto 2))));

process(clk)
begin

    if rising_edge(clk) then
        if wr_en='1' then
            ram_block(to_integer(unsigned(wr_addr))) <= data;
        end if;

        rda_reg <= rd_addr;

    end if;
end process;


process(rda_reg, d)
begin
    case rda_reg(1 downto 0) is
        when "11" =>
            q <= d(31 downto 24);
        when "10" =>
            q <= d(23 downto 16);
        when "01" =>
            q <= d(15 downto 8);
        when "00" =>
            q <= d(7 downto 0);
        when others =>
            null;
    end case;
end process;

end rtl;







Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarApr2017

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search