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
No, you to replace your for loop with a counter, with counts one up each clock. ALuPin wrote: > Hi, > > is the following CAM-implementation > synthezisable? How does a synthesis tool handle the for-loop > in real hardware? > > http://www.geocities.com/deepakgeorge2000/cam.htmArticle: 70626
mamta.chalana@st.com (mamtachalana) wrote in message news:<8dcc918.0406212237.5e14ffa8@posting.google.com>... > i want to use system verilog for system modelling,kindy tellme how can > i use that and how can i write code > suppose for example i want to make model of and gate with test benches > how do i compile my code > which compiler is required? > tell me the whole details > mamta I am not aware of any SystemVerilog support for FPGA flow. And not much is available for ASIC design either yet although most all the big EDA guys are committed to supporting it. You should be looking in the comp.lang./verilog, alot more people there know about it. Also google for systemverilog to get the latest news and status. Q do you really need sv at all, the new stuff is really for high level verification. If you only want to model gates, you only need plain verilog. regards johnjakson_usa_comArticle: 70627
Hal Murray wrote: > There are two parts to makefiles. One is the sequence of commands > needed to recreate something. The other is that is collects all > the parameters/options/flags in one place. Most software geeks > consider the makefile to be a source file and include it with the > other source files in some sort of source-code control system. > > Does xflow (and friends) have a single file where that sort of info > is collected? > Yes, similar but it is slightly different from the general make file process. Xflow will create a .flw and that will list all intermediate programs that need to be run to complete all flows. It lists the executable name, all input, output and trigger files as well as the report files. The file is pretty much self-documented but there is more on it in the manual if you need to learn more. There are also .opt files produced or can be hand-written if you want to create a unique flow. The .opt file does two things. It tells which programs need to be run for a particular flow and allows you to set all individual options for a particular sub-program. For instance, if you want to run the -mhf switch for netgen (will write out a separate timing netlists and SDF for each level of hierarchy in the design), then you can do this in the opt file for the -tsim switch. To take my first example again: xflow -implement high_effort -tsim modelsim_verilog <design>.edf If you run this command, an fpga.flw file will be created that will list all sub-programs (i.e. ngdbuild, map, par, etc.) necessary for an FPGA flow. If you want to add another program, say you want to automatically open floorplanner at the end of a run or you want to run your simulator for a timing simulation, you can add those programs to this file if you want however the general flow programs are all there already for you. This command-line will also create two .opt files, high_effort.opt and modelsim_verilog.opt. Those files will list the sub-programs necessary to run a high effort implementation run in the order they need to be run. It also lists all of the default options for the individual programs and allows you to modify or add addition options if you so choose. Similarly, the modelsim_verilog.opt file lists the programs to create a Verilog timing simulation netlist for ModelSim as well as all of the suggested options for that flow. This is where you would add the -mhf switch I mentioned above to the netgen section of this file if you wanted that capability added to the flow. If you want to complete the custom execution of floorplanner after the run or the running of the simulator after creating the timing simulation netlist, you would add those calls to these .opt files. Again, the .opt files are fairly intuitive, generally you can have xflow create the initial files for your run and then you make minor modification if necessary to get exactly what you want. Xflow is fairly easy to use and that reason alone is a good enough for me to use it but the other benefit it provides, even if you use other scripting methods is that it somewhat shields you from the minor differences/changes than happen to individual tools in the flow as enhancements are made. As recommended defaults change, as switches are added to reveal new capabilities and as flows change to address new design, implementation and verification methodologies, xflow adjusts to this, not you adjusting your hand-crafted make/CSH/Perl. etc. script. That exact same command above could run the 4.1i tools as it does the 6.2i tools today however if you created your own script to run the individual tools, some adjustments would likely need to be made to do the same. Or lets say you have now added equivalence checking to your verification methodology, all you would need to do is add the "-ecn formality_verilog" switch to the above execution and an equivalency checking netlists will also be produced. Again, it would be more difficult to add this capability to a custom script to run the individual programs. Try it out. I would be interested to hear your feedback on it. -- BrianArticle: 70628
74HCT series logic, for instance, is CMOS yet fully compatible with the 3.3V interface as long as the series resistors are used on the inputs (or I/Os). The 74HCT input levels are specified for TTL levels. The big question is what are the logic level requirements that you're interfacing with? Don't expect to replace a SYSTEM on a chip with a Spartan/SpartanXL. Have you checked out the densities of those old devices? "Naimesh" <t_naimesh@rediffmail.com> wrote in message news:ecee4f8a.0406211935.6d22115c@posting.google.com... > Is it possible to interface both CMOS and TTL devices to a 3.3 V > device? This is because I have to replaced a SOC on the alreay > designed board and dont want to change the design too much.Article: 70629
As per Xilinx Answer Record 12995: Q. When I initialize my JTAG chain in iMPACT, why does iMPACT identify a Spartan-II/E device as a Virtex/-E? A. Spartan-II and Virtex have identical IDCODEs, and are therefore indistinguishable in a JTAG chain. (The same holds true for Spartan-IIE and Virtex-E.) You may continue to program the Spartan-II/E device normally by assigning the Spartan-II/E bit file in iMPACT. Shalin- Oleg Slonsky wrote: > Dear Sir/ Madame, > > > > We have the following problem and we hope you could help us. > > > > On the printed board, produced by our Institute, we have installed the > microchip XC2S200E-PQ208. In order to download our project we have installed > WebPack 6.2i and connected to XC2S200E-PQ208 via port JTAG by Parallel Cable > III. > > In the program IMACT in the microchips autodetection mode this microchip was > detected as XCV200E with identification 10A1C093 . > > What is wrong? Whether the microchip is nor working correctly or > software is not correct? Or any other problem? > > What is the identification of microchip XC2S200E-PQ208? > > > > We will greatly appreciate any help of you ! > > > > With respect and the best wishes, > > Oleg Slonsky. > >Article: 70630
Problems keeping instantiated ROM in Xilinx XST.
Say I have a rom named rom16x16. It consists of 16 - 16x1 ROM primitive
instantiations from the xilinx library.
How do I force xilinx to keep this ? The code is being combined
into only one ROM (even though I have "init'd" the ROMS to different
values.
I tried using "keep heirarchy" under synthesis properties but that was a
no go. I'm at a loss as to what to do here. I do need the roms to be
separate (rather than a 64 byte rom) because I need to use them in
parallel for my particular application. Also, I took the basic rom16x16
and instantiated 4 components as rom16x16, rom16x16_2, rom16x16_3,
rom16x16_4, and I am also using them as "RAM" for now just for
simulation/rough design size purposes. I will stick in the actual 16x16
RAM units next. Spartan 3 is the chip architecture. Webpack XST 6.2 is
the sythesis engine.
Thanks!
D
code follows:
**************
rom0: rom_16x16
port map(coef_rom0_out(15 downto 0), addr);
coef_rom0_out(17 downto 16) <= "00";
ram0: rom_16x16
port map(coef_ram0_out(15 downto 0), addr);
coef_ram0_out(17 downto 16) <= "00";
rom1: rom_16x16_2
port map(coef_rom1_out(15 downto 0), addr);
coef_rom1_out(17 downto 16) <= "00";
ram1: rom_16x16_2
port map(coef_ram1_out(15 downto 0), addr);
coef_ram0_out(17 downto 16) <= "00";
rom2: rom_16x16_3
port map(coef_rom2_out(15 downto 0), addr);
coef_rom2_out(17 downto 16) <= "00";
ram2: rom_16x16_3
port map(coef_ram2_out(15 downto 0), addr);
coef_ram2_out(17 downto 16) <= "00";
rom3: rom_16x16_4
port map(coef_rom3_out(15 downto 0), addr);
coef_rom3_out(17 downto 16) <= "00";
ram3: rom_16x16_4
port map(coef_ram3_out(15 downto 0), addr);
coef_ram3_out(17 downto 16) <= "00";
********
the 16x16 rom is as follows:
**************************
library UNISIM;
use UNISIM.VComponents.all;
library IEEE;
use IEEE.std_logic_1164.all;
use IEEE.std_logic_unsigned.all;
entity rom_16x16 is
port (o: out std_logic_vector(15 downto 0);
a: in std_logic_vector(3 downto 0));
end rom_16x16;
architecture xilinx of rom_16x16 is
component rom_16x1
generic (init_val: string := "0000");
port (O : out std_logic;
A3, A2, A1, A0 : in std_logic);
end component;
begin
U0: rom16x1 generic map(x"14")
port map (O => o(0), A0 => a(0), A1 => a(1), A2 => a(2), A3 => a(3) );
U1: rom16x1 generic map(x"D")
port map (O => o(1), A0 => a(0), A1 => a(1), A2 => a(2), A3 => a(3) );
U2: rom16x1 generic map(x"1C")
port map (O => o(2), A0 => a(0), A1 => a(1), A2 => a(2), A3 => a(3) );
U3: rom16x1 generic map(x"4")
port map (O => o(3), A0 => a(0), A1 => a(1), A2 => a(2), A3 => a(3) );
U4: rom16x1 generic map(x"17")
port map (O => o(4), A0 => a(0), A1 => a(1), A2 => a(2), A3 => a(3) );
U5: rom16x1 generic map(x"0")
port map (O => o(5), A0 => a(0), A1 => a(1), A2 => a(2), A3 => a(3) );
U6: rom16x1 generic map(x"0")
port map (O => o(6), A0 => a(0), A1 => a(1), A2 => a(2), A3 => a(3) );
U7: rom16x1 generic map(x"0")
port map (O => o(7), A0 => a(0), A1 => a(1), A2 => a(2), A3 => a(3) );
U8: rom16x1 generic map(x"0")
port map (O => o(8), A0 => a(0), A1 => a(1), A2 => a(2), A3 => a(3) );
U9: rom16x1 generic map(x"0")
port map (O => o(9), A0 => a(0), A1 => a(1), A2 => a(2), A3 => a(3) );
U10: rom16x1 generic map(x"0")
port map (O => o(10), A0 => a(0), A1 => a(1), A2 => a(2), A3 => a(3) );
U11: rom16x1 generic map(x"0")
port map (O => o(11), A0 => a(0), A1 => a(1), A2 => a(2), A3 => a(3) );
U12: rom16x1 generic map(x"0")
port map (O => o(12), A0 => a(0), A1 => a(1), A2 => a(2), A3 => a(3) );
U13: rom16x1 generic map(x"0")
port map (O => o(13), A0 => a(0), A1 => a(1), A2 => a(2), A3 => a(3) );
U14: rom16x1 generic map(x"0")
port map (O => o(14), A0 => a(0), A1 => a(1), A2 => a(2), A3 => a(3) );
U15: rom16x1 generic map(x"0")
port map (O => o(15), A0 => a(0), A1 => a(1), A2 => a(2), A3 => a(3) );
end xilinx;
**********************
Article: 70631Out of interest, would anyone happen to know what is the difference in performance between a Virtex fpga (not vitex 2) and its equivalent Spartan3??? Thanks CArticle: 70632
If the BlockRAM explanation in the Xilinx data book is not clear, I consider that my problem. Let me fix this here: The BlockRAM is a synchronous device, nothing happens without a clock edge. Let¹s look at just one port. Read operation: You have to apply the address and control inputs a (very short) set-up time before the active (optional polarity) clock edge. (DI data input lines are not used). The active clock edge stores the information, decodes the address, reads the data content at that location and puts it onto the DO output lines. There is a very short set-up time, but a relatively long ³clock-to-out² read time, since it includes address decode and read and write strobes. Write operation: You have to apply the address, Data and control inputs a (very short) set-up time before the active (optional polarity) clock edge. The active clock edge stores the information, decodes the address, creates a read and a write pulse, writes the DI data into the addressed location, and also reads the data content at that location and puts it onto the DO output lines. The user has control of the relative timing of write and read sequence. Either WRITE_FIRST ³write before read², forcing the written data onto the DO outputs (of marginal interest) Or READ_FIRST ³read before write² , forcing the ³old² data onto the DO outputs and keeping them there until the next operation. Or NO_CHANGE, don¹t change the D0 output, causing it to maintain its data until the next read operation. These options are new to Virtex-II (and Spartan3). Virtex and Spartan2 always did write before read. Dual-Port operation: The two ports are independent, except for special rules of validity when one port writes into a location that the other port is reading from (I posted the gory details a while ago). In your case, you perform a synchronous write to the Top-of-Stack address, while (for free) simultaneously also reading this new data on DO. You then can pop the stack synchronously with the decremented address. I hope this clarifies things. Peter Alfke > From: rickman <spamgoeshere4@yahoo.com> > Reply-To: john@bluepal.net > Newsgroups: comp.arch.fpga > Date: Mon, 21 Jun 2004 16:59:38 -0400 > Subject: Re: RAM in Altera EABs and Xilinx Block Rams > > Peter Alfke wrote: >> >> Just to clarify Rickman's "Two-clock-cycle thing": >> Xilinx BlockRAMs need ONE clock to perform any operation, be it a read or a >> write. As a bonus, the write operation also performs a read operation on the >> same location, showing either the old or the new data (user option). >> And this is all on one port. You can obviously use the other port >> independently from the first. >> The one thing you cannot do is an asynchronous read without a clock edge. >> >> If anybody has any questions about Xilinx BlockRAMs, I am more than happy to >> explain. > > Perhaps I didn't understand the documentation. I think I got mixed up > in the description of the read port latches. Sometimes I forget the > distinction between latches and registers. > > First, let me say that I am designing a stack using a single block ram. > My understanding is that I can use the RAM as either a single port ram > with a single address bus, a write data bus and a read data bus or a > dual port ram with two independant interfaces like the single port > interface. > > Using the single port interface it appears to me that the address and > control signals are registered. Looking at the timing diagram for the > WRITE_FIRST option, I see that the data output changes with one clock > delay. So can I consider the register to be on the input side (address, > control) with the read data output using no register? I belive that > will work for a stack. When data is being pushed, the incremented > address is set up and the write is clocked in, while the data output is > steady until the clock edge (old top of stack). Following the clock > edge, the data written will be presented on the output (new top of > stack). To pop the stack, the address is decremented and a read is done > with the new data available following the clock edge (new top of > stack). A write (pop and push) is done by not changing the address and > registering a new write with the read data changing after the clock > edge. > > Will the single port WRITE_FIRST ram mode work this way? > > I also need program and data memories and the register delay may > interfere with full speed operation on these. I might be able to clock > the data and instruction memory from "not clock" to allow the read data > to be available during the second half of the current clock cycle. This > may result is a bit slower clock cycle, but it should be better than a > two clock cycle. > > -- > > Rick "rickman" Collins > > rick.collins@XYarius.com > Ignore the reply address. To email me use the above address with the XY > removed. > > Arius - A Signal Processing Solutions Company > Specializing in DSP and FPGA design URL http://www.arius.com > 4 King Ave 301-682-7772 Voice > Frederick, MD 21701-3110 301-682-7666 FAXArticle: 70633
D wrote:
> Problems keeping instantiated ROM in Xilinx XST.
>
> Say I have a rom named rom16x16. It consists of 16 - 16x1 ROM primitive
> instantiations from the xilinx library.
>
> How do I force xilinx to keep this ? The code is being combined
> into only one ROM (even though I have "init'd" the ROMS to different
> values.
>
> I tried using "keep heirarchy" under synthesis properties but that was a
> no go. I'm at a loss as to what to do here. I do need the roms to be
> separate (rather than a 64 byte rom) because I need to use them in
> parallel for my particular application. Also, I took the basic rom16x16
> and instantiated 4 components as rom16x16, rom16x16_2, rom16x16_3,
> rom16x16_4, and I am also using them as "RAM" for now just for
> simulation/rough design size purposes. I will stick in the actual 16x16
> RAM units next. Spartan 3 is the chip architecture. Webpack XST 6.2 is
> the sythesis engine.
>
My guess at fixing this would be to either remove the ROM16X1 component
declaration or you can add the attribute:
attribute BOX_TYPE of
ROM16X1 : component is "PRIMITIVE";
Better for you to just remove and not use the component declaration as
it is not necessary and if you mis-declare it, can cause it not to work
properly. The component declaration you have does mis-declare a ROM16X1
as the generic should be a bit_vector and named INIT not init_val bu the
fact you named it rom_16x1 rather than rom16x1 means that that
declaration is meaningless any ways.
Also, the INIT attribute needs to be a 4-digit hex value (16-bits) not
2-digit (8-bits). I also suggest simulating this as it might help you
localize the problem better if these suggestions do not work.
-- Brian
Article: 70634ALuPin@web.de (ALuPin) wrote in message news:<b8a9a7b0.0406220109.67a062ac@posting.google.com>... > Hi newsgroup users, > > maybe you can help me on the following question: > > Does Modelsim remove registered signals which are unused or not > connected to output pins? It doesn't for the standard level of optimisation. If you enable -O5/-fast then it may well do. > Is there a possibility to avoid this without using output pins? You can either compile with the default optimisation level, or use an option like +acc to make sure it retains a particular net/register. > Kind regards Cheers, JonBArticle: 70635
Paulo Dutra <paulo.dutra@NOSPAM.com> wrote in message news:<40D73572.803@NOSPAM.com>... > You could also allow XST to read in the "module" NGC with > -read_cores option. Xst will read in your NGC to recognize > the logic and infer IO appropriately to the ports that need > IO buffers. > > However, your solution of a wrapper is more general and more appropriate. > As it is possible to use this approach in other synthesis tools. > As your customer may prefer a 3rd party synth tool over XST. Paulo- Interesting option. I hadn't noticed that before. Thanks. As you said, the wrapper is more general and more appropriate for this particular issue. Cheers, JakeArticle: 70636
C,
Not enough information, so I will answer a lot of what you did not ask.
Virtex is 6 years old, 0.22 micron technology, Core Vccint = 2.5 volts.
You can look up its speed and capabilities on the website to see how
it performs. Just as a measure, designs can run at 150 MHz with some
care. A real workhorse, and still being used, but seldom do we hear
about it being designed into new equipment. The Mars rovers use 6
V1000's each, for example, to keep the wheels turning, as well as other
supervisory tasks. It has 5V compatibility, hot swap bus without any
power sequencing, and some other really nice features that still make it
a chip of choice. Works at PCI-66 MHz. Has the first Digital Locked
Loops(DLL), dual port BRAM.
http://www.xilinx.com/prs_rls/design_win/0412_marsrover.htm
Virtex E is about 5 years old, 0.18/0.15u hybrid, core Vccint=1.8 volts.
Designs can run at 200 MHz with some care. Virtex E is still being
designed in, but has virtually replaced all Virtex designs (as it is pin
compatible and lower cost), but is now less of a designers choice with
Virtex II and Virtex II Pro being the more common choice. Like Virtex,
it is also 5V tolerant, and hot swap bus friendly. Also a PCI-66 MHz
choice. More DLL's. More BRAM.
Virtex II is about 3 years old, 0.15u, core Vccint=1.5 volts. Designs
can run at 350 MHz with some care, with some designs running a bit
faster in the fastest speedgrade. Virtex II is being designed into many
new boards. VII requires a resistor for 5V tolerance, and also requires
that Vcco be biased on to be hot swap bus friendly. First PCI-X 133 MHz
FPGA. First appearance of the Digital CLock Manager, with both a DLL,
and a frequency synthesizer (DFS). More BRAM.
Virtex II Pro is the lead family, at 0.13u, and also with a Vccint of
1.5 volts. As VII Pro is a better price/performance/capability choice,
with designs at 420 MHz with some care, it is definitely the hands down
winner right now, with an amazing number of new design-ins every month.
Added IBM 405 PowerPC's (tm), and multi-gigabit 3.125 Gbs transceivers.
More BRAM. Faster IO.
http://www.xilinx.com/prs_rls/silicon_vir/0411v2_recrev.htm
Virtex II Pro-X exchanges the 3.125 Gbs transceiver for 10 Gbs
transceivers. An industry first.
http://www.xilinx.com/prs_rls/end_markets/0472atca10g.htm
Virtex 4 has been announced as being the next family, at 90 nm,
Vccint=1.2 volts, and a performance of about 500 MHz (and more), and
general IOs capable of 1 Gbs. See the press announcements for all of
the features that are new.
http://www.xilinx.com/prs_rls/silicon_vir/0465v4arch.htm
Spartan 3 is about a year old, 90 nm with a Vccint=1.2 volts, and was a
redesign of Virtex II for cost. It offers similar performance to a slow
speed grade Virtex II, but with fewer IO standards, and some other
things removed to reduce the die area and cost. It has DCMs, and 18X18
multipliers. It is commonly used to replace ASICs up to very large
volumes (see our press release on sold to date figures).
http://www.xilinx.com/prs_rls/silicon_spart/0471spartanleadership.htm
So, if I take you literally, the original Virtex part is probably half
the speed of a Spartan 3, and since the Virtex part did not have 18X18
multipliers, or DCM's, a Spartan 3 would be a much more powerful chip,
as well as being far less expensive.
The original Virtex is also available as Spartan 2, as is the Virtex E
line as Spartan 2E (smaller gate count parts).
6 products, in 6 years! It will be my 6 year anniversary here at Xilinx
at the end of this month, and I have had the privilege to be involved in
all of the above products.
Austin
chuk wrote:
> Out of interest, would anyone happen to know what is the difference in
> performance between a Virtex fpga (not vitex 2) and its equivalent
> Spartan3???
>
> Thanks
> C
Article: 70637Miika Pekkarinen <miika.nospam1@ihme.org> wrote: : Hello, : I have Altera Quartus II 4.0 software and I managed to successfully install : it on a Debian Linux machine (with Intel Pentium 4 processor). However, : always when I try to start the software, I will get the following messages: : "Choose the preferred look and feel for the Quartus II software..." : I select Quartus II and click OK. After that I will get: : "MainWin license not available -- to run the Quartus II software, you : must specify a valid license file that contains a MainWin license." : I have searched Altera web sites and newsgroups but was unable to find out : what is this MainWin license. So does anybody know what it is, where could : I get one and how to specify the license file for Quartus? Quartus is written as a Windows programm. To run it under Linux, Altera (like Xilinx with their ISE ) have choosen to use the MainWin libraries. They have to pay licenses for ever MainWin installation. From what I have read above, you already have the media, probably from some distributor. So ask the distributor for a license too. A 30 (or was it 60) day free evaluation license is available, otherwise you have to pay. Bye -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 70638
Depends. Speed grade, critical paths in design both play into it.
Roughly speaking the 3S-5 is around the same speed as a VirtexE-6, for ~16
bit arithmetic. Faster for random logic without carry chains.
Regardless, it is not a linear relationship. Spartan3 has a different
architecture and the speeds of different elements changed by different
amounts.
chuk wrote:
> Out of interest, would anyone happen to know what is the difference in
> performance between a Virtex fpga (not vitex 2) and its equivalent
> Spartan3???
>
> Thanks
> C
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 70639I'm looking forward to comments from the CAF regulars on that statement, Austin! Are we talking 'marketing' years or 'you can buy them' years? Is it true that in China your age counts from conception? Maybe Spartan 3 is following that rule? The extra 9 months to sort out the will we/won't we low-k thing. With tongue in cheek, Syms. "Austin Lesea" <austin@xilinx.com> wrote in message news:cb9p4v$cmu2@cliff.xsj.xilinx.com... > > Spartan 3 is about a year old,Article: 70640
Hey... i've made a CPLD board XL9572... it is way to small to put in a softcore uC like an 8051... ??? Any sugestion to a FPGA insead... and which one ? and is it possible to do a board my self ? i looked on this board : http://www.burched.biz/ but a lot of money for a student... and i think i can get made proff 2 sided pcb very cheap... Kasper ??? :)Article: 70641
I like to see diagrams of the functional elements to show how circuits work... "a picture is worth a thousand words"... The app note is more clear now that I see my mistake. But a block diagram showing the input registers and the output *latch* might help to make the circuit operation more clear. I don't recall if there is also an optional output register, if so, that should be added to the illustration as well. I seem to recall that the operation of the CLB RAM in the 4000E series was illustrated very well in this regards. It showed all the possible modes via registers, muxes and the write pulse generator. Something like that would be useful if added to Xapp 463. Peter Alfke wrote: > > If the BlockRAM explanation in the Xilinx data book is not clear, I consider > that my problem. Let me fix this here: > > The BlockRAM is a synchronous device, nothing happens without a clock edge. > Let¹s look at just one port. > > Read operation: > You have to apply the address and control inputs a (very short) set-up time > before the active (optional polarity) clock edge. (DI data input lines are > not used). > The active clock edge stores the information, decodes the address, reads the > data content at that location and puts it onto the DO output lines. There is > a very short set-up time, but a relatively long ³clock-to-out² read time, > since it includes address decode and read and write strobes. > > Write operation: > You have to apply the address, Data and control inputs a (very short) set-up > time before the active (optional polarity) clock edge. > The active clock edge stores the information, decodes the address, creates a > read and a write pulse, writes the DI data into the addressed location, and > also reads the data content at that location and puts it onto the DO output > lines. > > The user has control of the relative timing of write and read sequence. > Either WRITE_FIRST ³write before read², forcing the written data onto the DO > outputs (of marginal interest) > Or READ_FIRST ³read before write² , forcing the ³old² data onto the DO > outputs and keeping them there until the next operation. > Or NO_CHANGE, don¹t change the D0 output, causing it to maintain its data > until the next read operation. > These options are new to Virtex-II (and Spartan3). Virtex and Spartan2 > always did write before read. > > Dual-Port operation: > The two ports are independent, except for special rules of validity when > one port writes into a location that the other port is reading from (I > posted the gory details a while ago). > > In your case, you perform a synchronous write to the Top-of-Stack address, > while (for free) simultaneously also reading this new data on DO. > You then can pop the stack synchronously with the decremented address. > > I hope this clarifies things. > > Peter Alfke > > > From: rickman <spamgoeshere4@yahoo.com> > > Reply-To: john@bluepal.net > > Newsgroups: comp.arch.fpga > > Date: Mon, 21 Jun 2004 16:59:38 -0400 > > Subject: Re: RAM in Altera EABs and Xilinx Block Rams > > > > Peter Alfke wrote: > >> > >> Just to clarify Rickman's "Two-clock-cycle thing": > >> Xilinx BlockRAMs need ONE clock to perform any operation, be it a read or a > >> write. As a bonus, the write operation also performs a read operation on the > >> same location, showing either the old or the new data (user option). > >> And this is all on one port. You can obviously use the other port > >> independently from the first. > >> The one thing you cannot do is an asynchronous read without a clock edge. > >> > >> If anybody has any questions about Xilinx BlockRAMs, I am more than happy to > >> explain. > > > > Perhaps I didn't understand the documentation. I think I got mixed up > > in the description of the read port latches. Sometimes I forget the > > distinction between latches and registers. > > > > First, let me say that I am designing a stack using a single block ram. > > My understanding is that I can use the RAM as either a single port ram > > with a single address bus, a write data bus and a read data bus or a > > dual port ram with two independant interfaces like the single port > > interface. > > > > Using the single port interface it appears to me that the address and > > control signals are registered. Looking at the timing diagram for the > > WRITE_FIRST option, I see that the data output changes with one clock > > delay. So can I consider the register to be on the input side (address, > > control) with the read data output using no register? I belive that > > will work for a stack. When data is being pushed, the incremented > > address is set up and the write is clocked in, while the data output is > > steady until the clock edge (old top of stack). Following the clock > > edge, the data written will be presented on the output (new top of > > stack). To pop the stack, the address is decremented and a read is done > > with the new data available following the clock edge (new top of > > stack). A write (pop and push) is done by not changing the address and > > registering a new write with the read data changing after the clock > > edge. > > > > Will the single port WRITE_FIRST ram mode work this way? > > > > I also need program and data memories and the register delay may > > interfere with full speed operation on these. I might be able to clock > > the data and instruction memory from "not clock" to allow the read data > > to be available during the second half of the current clock cycle. This > > may result is a bit slower clock cycle, but it should be better than a > > two clock cycle. > > > > -- > > > > Rick "rickman" Collins > > > > rick.collins@XYarius.com > > Ignore the reply address. To email me use the above address with the XY > > removed. > > > > Arius - A Signal Processing Solutions Company > > Specializing in DSP and FPGA design URL http://www.arius.com > > 4 King Ave 301-682-7772 Voice > > Frederick, MD 21701-3110 301-682-7666 FAX -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 70642
Rick, Try this instead. (The POPs are different) Put the BRAM in WRITE_FIRST mode. PUSH - Write to location at incremented stack pointer, new output is new data. POP - Read output data, decrement stack pointer so new output is new top of stack WRITE - Write new data to top of stack, read old top of stack. Sounds ideal for a Xilinx BRAM to me, all happens on a single clock edge. The BRAM always presents the top of stack at its output so it's available right away. Anyway, that's what I did.. cheers, Syms. "rickman" <spamgoeshere4@yahoo.com> wrote in message news:40D79D6D.9ACFF848@yahoo.com... > Push - write to location at incremented stack pointer, update register > to new data. > Pop - read location at decremented stack pointer, update register to > data read. > Write - write to location at stack pointer, update register to new data. > write is used when an instruction modifies the top of stack without > popping. >Article: 70643
> Hey... > > i've made a CPLD board XL9572... it is way to small to put in a softcore uC > like an 8051... ??? > > > Any sugestion to a FPGA insead... and which one ? and is it possible to do a > board my self ? > > i looked on this board : http://www.burched.biz/ > > but a lot of money for a student... > > and i think i can get made proff 2 sided pcb very cheap... Is this a good board ???? : http://www.coreworks.pt/basicboard.htm KasperArticle: 70644
Symon, Very funny. So we are unbelievably successful with S3. Is that our fault that we somehow did not figure that they would be instantly shipped once they got packaged? Triple whammy: 1) great part 2) great price 3)dot.com ending. Did you bother to read the S3 press release? 500K S3's in 2003? That is one helluva lot of FPGAs..... Some would have you beleive that 90nm was "too risky" and "had availability issues" .... that is until they have their 90nm offering! Never even considered lo-K for S3 (too much $$$ for too little benefit). Lo-K was a Virtex II Pro 'issue' that we had to correct by process tweaks and design. Let's face it, if we can still meet all of the specifications without lo-K, why bother with the cost and reliability issues? Austin Symon wrote: > I'm looking forward to comments from the CAF regulars on that statement, > Austin! Are we talking 'marketing' years or 'you can buy them' years? Is it > true that in China your age counts from conception? Maybe Spartan 3 is > following that rule? The extra 9 months to sort out the will we/won't we > low-k thing. > With tongue in cheek, Syms. > "Austin Lesea" <austin@xilinx.com> wrote in message > news:cb9p4v$cmu2@cliff.xsj.xilinx.com... > >>Spartan 3 is about a year old, > > >Article: 70645
"Oleg Slonsky" <oleg@uniirt.com.ua> wrote in message news:cb8n20$nt$1@toster.Te.NeT.UA... > Dear Sir/ Madame, > > We have the following problem and we hope you could help us. [snip] ...we have XC2S200 ... > In the program IMACT in the microchips autodetection mode this microchip was > detected as XCV200E with identification 10A1C093 . xilinx (sw) is wrong! simply disregard this message! xilinx.openchip.orgArticle: 70646
Thanks for the (late) praise. I was really proud of my drawing. :-) But it gets more complicated in BRAMs, what with the write and the read pulse dancing around each other. Still, food for thought... Peter Alfke > I don't recall if there is also > an optional output register, if so, that should be added to the > illustration as well. I seem to recall that the operation of the CLB > RAM in the 4000E series was illustrated very well in this regards. It > showed all the possible modes via registers, muxes and the write pulse > generator. Something like that would be useful if added to Xapp 463. > > >Article: 70647
Martin Thompson wrote:
> When I tried XFLOW, it seemed to want to create a batch file called
> xflow.bat with all the commands in it that needed running. Next time
> I typed an XFLOW command, all it did was run the old xflow.bat from
> the current directory. That had me bemused for a long time - i take
> it everyone that uses it does so on Unix (where . isn't on the path
> like it is in windos land).
Interesting. I did not know about this. I generally use XFlow on
Solaris and now Linux so I have not encountered this. For UNIX
machines, it creates an xflow.scr file which is a CSH script of all of
the commands however I personally never use it. You can also have it
write out the script in TCL if you prefer. If you want, that script can
be used to integrate into other scripts or used stand-alone if you want
to get away from the xflow "shell". Similarly for the .bat file on a PC
but I guess it has this interesting side effect. I will pass this on to
that group so that they can evaluate how to get around that problem.
Thanks for the feedback.
>
> Speaking of batch file processes - does anyone know how to find out if
> XST generated any errors - in my experiments, it returns the same
> ERRORLEVEL every time.
Don't know about this. I just tried to run XST from xflow where I
introduced a syntax error into one of my Verilog files and got back the
response:
ERROR:Xflow - Program xst returned error code 6. Aborting flow execution...
There it looks like XST is specifying an error code that you could key
off of. Perhaps it is specific to the error or situation you have created.
> I'm sure I've seen this with other tools as well, which means that the
> compilation runs through to completion on the old files! One
> hackaround I've seen from a reputable source is to do your
> implementation in a clean directory every time, copying in the UCF,
> EDF eetc. But that seems nasty!
You could start each run in a clean directory or else build into your
script to smarts to either move some of the relevant input files to the
next portion of the flow into another directory (backup of previous run)
or else just delete them. That way when you get to the next program, it
should error out saying file not found if you did not catch the error
code before. In my experience however, most programs do specify
non-zero error codes when an error occurs and if you properly catch
them, you can abort the script execution yourself. When I used CSH as
my main scripting language to run the tools, I use to do it like:
ngdbuild $NGDBUILD_OPTIONS $part $ucf $ngdinput >&! ngdbuild.log
if ($status != 0) then
echo "Ngdbuild did not successfully finish, do you wish to"
echo "check ngdbuild.log for errors."
echo -n " Y/N : "
set ans = $<
set ans = `echo $ans |sed -e 's/ *$//'`
if ( "${ans}" =~ [Yy] ) then
less ngdbuild.log
endif
exit(1)
endif
That almost never failed me but it has been a while since I have run the
tools in this manner.
-- Brian
Article: 70648
Provided you don't use the carry chain.
Austin Lesea wrote:
> C,
>
> Virtex II is about 3 years old, 0.15u, core Vccint=1.5 volts. Designs
> can run at 350 MHz with some care, with some designs running a bit
> faster in the fastest speedgrade. Virtex II is being designed into many
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 70649
rickman <spamgoeshere4@yahoo.com> wrote in message news:<40D7CE00.DE3256AC@yahoo.com>...
> I am using an EAB as a RAM for program storage for an MCU in an Altera
> ACEX FPGA. But I can't seem to find info on how to initialize the RAM.
> I will at least need a boot strap program to read an external Flash into
> the RAM. I found information about creating MIF files and RIF files.
> But they don't say much about how they get used. Can anyone give me the
> details? I assume this initialization data goes into the bit stream
My recommendation is to use the MegaWizard plugin manager and examine the
generated VHDL to see how they do it, then you have the option to roll your
own. Basically you pass the MIF file as a Generic to the instantiated
component. It works smoothly. That is, for Stratix... The options for ACEX
may be different.
COMPONENT altsyncram
GENERIC (
<...>
INIT_FILE : STRING := "YourFile.mif";
INIT_FILE_LAYOUT : STRING := "PORT_A";
);
> using the tools, no? Is there a way to initialize the RAM in a VHDL
> simulation other than to use the variable initialization of VHDL? That
> seems very messy.
Yes. See the Quartus Help on Opening Embedded RAM, and Update Simulator
with Current Memory. You have to insert a simulation breakpoint and do
it then... (Though at this very moment I'm trying to do this with a MegaRAM,
and struggling.)
Hope this helps,
-rajeev-
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