Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
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
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
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, MarkArticle: 92227
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
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> What SoC interconnect are you using? AMBA AXI. Cheers, JonArticle: 92230
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. MartinArticle: 92231
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
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
>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, MartinArticle: 92234
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
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: 92236Yes, 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
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 JochenArticle: 92238
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 JavierArticle: 92239
Thanks Tim, it works now, I was not drunk, but I did not see it! MarcoArticle: 92240
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
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
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
> 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
>> >>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? MartinArticle: 92245
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 AlfkeArticle: 92246
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"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
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.DATArticle: 92249
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:
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