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
Hi, Can any help me out to understand, how does SOC differs from ASIC ? -Muthu.Article: 72676
bonetiger wrote:
> Hi,
>
> I generated two FIFOs using Xilinx ISE CoreGen.
>
> Both FIFOs are 64-bit wide, but one FIFO depth is 16, the other is 64.
>
> After doing the mapping, I was surprised to find that both FIFOs use the same amount of BlockRam.
>
> I cannot understand the reason since the 16-depth FIFO will definately use less memory than the 64-depth FIFO.
>
> Please give some idea about this. Thanks.
Surely this isn't homework. Memory is only available in certain widths
and certain depths. If you exceed either of those two, more memories
will have to be used, even if the first one is not fully utilized. Your
wide bus is the limiting factor here, not the depth or the total number
of bits used.
Have fun,
Marc
Article: 72677On Fri, 27 Aug 2004 21:39:14 -0700, bonetiger wrote: > Hi, > > I generated two FIFOs using Xilinx ISE CoreGen. > > Both FIFOs are 64-bit wide, but one FIFO depth is 16, the other is 64. > > After doing the mapping, I was surprised to find that both FIFOs use the same amount of BlockRam. > > I cannot understand the reason since the 16-depth FIFO will definately use less memory than the 64-depth FIFO. > > Please give some idea about this. Thanks. XST tends to use block ram even when it doesn't need to. In the 16 deep FIFO use a directive to force it to use LUT RAMs. The example below has directives for both XST and Precision, the // synthesis is XST, the // pragma is Precision. reg [WIDTH-1:0] ram[15:0]; // synthesis attribute ram_style of ram is distributed // pragma attribute ram block_ram false For the 64 deep FIFO block RAM is the better choice. For depths of 16 the trade off between LUT Ram and Block RAM is that LUT RAMs are generally faster and easier to place, Block RAMs are cheaper. The minimum depth of the Block RAMs is 512, (512x36), so if you are using them for FIFOs you might as well make them 512 deep.Article: 72678
Hi Steven, It would appear from this article that the designer used another chipset to do the Camera Link interface and not the IO pins of the Virtex directly. This is contrary to what I am thinking about. However, considering what you are saying, it does seem possible that the link can be done directly with either Virtex or Spartan3 IOs, although I haven't found anybody to tell me that they actually have. > > Both Virtex-II Pro and Spartan-3 support LVDS signals. I don't have a > Spartan-3 specific design but here's an example of one such product using > Virtex-II. > http://www.transtech-dsp.com/fpga/custom_mod_exam.asp > > Essentially, Channel Link is a 7:1 LVDS interface with a 66 MHz input clock. > Use the CLKFX and CLKFX180 outputs from a DCM. Set the CLKFX_MULTIPLY=7, > CLKFX_DIVIDE=2. Use DDR flip-flips and LVDS input or output buffers for > either the input (receiver) or output (transmitter). 66 MHz * 7/2 * 2X > (DDR) = 462 Mbps. > > --------------------------------- > Steven K. Knapp > Applications Manager, Xilinx Inc. > General Products Division > Spartan-3/II/IIE FPGAs > http://www.xilinx.com/spartan3 > --------------------------------- > Spartan-3: Make it Your ASICArticle: 72679
I'm trying to produce a square wave clock that is a fifth of the
frequency of a faster clock. This means that I must use both the falling
edge and rising of the clock. XST complains "Signal cnt cannot be
synthesized, bad synchronous description.", I have since learned that I
can only have one event per process.
How do I produce a counter that counts on both clock edges?
Regards
Andrew
entity div5 is
port (
clk : in std_logic;
q : out std_logic);
end div5;
architecture div5_arch of div5 is
signal cnt : std_logic_vector (2 downto 0) := "000";
begin
process (clk)
begin
if(clk'event and clk = '0')then
if(cnt = "110") then
cnt <= "000";
else
cnt <= cnt + 1;
end if;
end if;
if(clk'event and clk = '1')then
if(cnt = "010") then
cnt <= "100";
else
cnt <= cnt;
end if;
end if;
end process;
q <= cnt(2);
end div5_arch;
--
Spartan3 configuration JTAG download tool for GNU/Linux available from
http://www.rogerstech.co.uk/xc3sprog/
Article: 72680
Hi, all ,
I am using ISE6.2 and modelsim5.8b. My design is composed of two
modules, one is VDHL design ,and the other is verilog design. Now I want to
combine them together in a top level file (in vhdl) and simulate the whole
design. Can I just instantiate the verilog design module with a compoenent
in the top file and write a testbench for the top file.
I have done this , but it fails when binding the verilog module
(rx_backend).
# ** Failure: Default binding had errors for entity 'rx_backend' on the
component declaration of line 220. See the compiler messages.
Could u give any idea on how to do the mixed vhdl and verilog design and
simulation?
Many thanks.
Jimmy
Article: 72681Hello: A SOC is a System On Chip and is independent of where you implement it, a FPGA a ASIC or wherever you want. An ASIC one of the possible ways to implement the SOC. Regards Javier Castillo jcastillo@opensocdesign.com www.opensocdesign.com muthusnv@yahoo.co.in (Muthu) wrote in news:4f8e807b.0408280300.129f3088 @posting.google.com: > Hi, > > Can any help me out to understand, how does SOC differs from ASIC ? > > -Muthu.Article: 72682
Andrew Rogers wrote: > > I'm trying to produce a square wave clock that is a fifth of the > frequency of a faster clock. This means that I must use both the falling > edge and rising of the clock. XST complains "Signal cnt cannot be > synthesized, bad synchronous description.", I have since learned that I > can only have one event per process. > > How do I produce a counter that counts on both clock edges? > > Regards > Andrew > > entity div5 is > port ( > clk : in std_logic; > q : out std_logic); > end div5; > > architecture div5_arch of div5 is > signal cnt : std_logic_vector (2 downto 0) := "000"; > > begin > process (clk) > begin > if(clk'event and clk = '0')then > if(cnt = "110") then > cnt <= "000"; > else > cnt <= cnt + 1; > end if; > end if; > if(clk'event and clk = '1')then > if(cnt = "010") then > cnt <= "100"; > else > cnt <= cnt; > end if; > end if; > end process; > q <= cnt(2); > end div5_arch; This program is trying to describe something that can not be built using standard elements found inside an FPGA. Instead of trying to think in VHDL, try thinking in terms of the logic. Forget the code for a moment and figure out what logic would be generated to do what you want. I can think of three ways to do what you want. One is to use a clock that is twice the frequency (generated in a PLL/DLL in the FPGA). Your design is a bit unusual in that you do different things on the rising and falling edges of the original clock. You will need to reference this clock to distinguish the two actions. A second way is to use both a rising edge triggered register and a falling edge register, each a function of the other. Your logic will need to change from what you have above. The third is to use two registers, but one logic path with a MUX in the front to switch registers as required by your function definition. Since this is a very odd function to be implementing as part of a job, I assume it is a homework assignment. So I won't give any more details... But the main idea is to use VHDL to describe your logic... *AFTER* you have figured out what it must be. Don't try to code your problem without having a solution in mind. -- 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: 72683
Hi Andrew In real hardware the trick is to use a 5-stage shift register with an inverter between the output of the last stage and the input of the first stage. This should be easy to implement in VHDL. Mogens Pelle "Andrew Rogers" <andrew@_NO_SPAM_rogerstech.co.uk> skrev i en meddelelse news:4130963b$1_1@127.0.0.1... > I'm trying to produce a square wave clock that is a fifth of the > frequency of a faster clock. This means that I must use both the falling > edge and rising of the clock. XST complains "Signal cnt cannot be > synthesized, bad synchronous description.", I have since learned that I > can only have one event per process. > > How do I produce a counter that counts on both clock edges? > > Regards > Andrew > > > > entity div5 is > port ( > clk : in std_logic; > q : out std_logic); > end div5; > > architecture div5_arch of div5 is > signal cnt : std_logic_vector (2 downto 0) := "000"; > > begin > process (clk) > begin > if(clk'event and clk = '0')then > if(cnt = "110") then > cnt <= "000"; > else > cnt <= cnt + 1; > end if; > end if; > if(clk'event and clk = '1')then > if(cnt = "010") then > cnt <= "100"; > else > cnt <= cnt; > end if; > end if; > end process; > q <= cnt(2); > end div5_arch; > > -- > Spartan3 configuration JTAG download tool for GNU/Linux available from > http://www.rogerstech.co.uk/xc3sprog/ >Article: 72684
rickman <spamgoeshere4@yahoo.com> wrote in message news:<4130AEF9.BF3AD39D@yahoo.com>... > Since this is a very odd function to be implementing as part of a job, I > assume it is a homework assignment. So I won't give any more > details... I see this sort of answer a lot on this forum and, while I agree that we don't need to be doing someone's homework, do we really need to make this sort of statement? It's condescending and really unnecessary. If you don't want to give details, just leave them out. Let's give folks the benefit of the doubt and maybe we won't scare people away. I -have- had to implement this sort of thing as part of a job (more than once, in fact). Another way to do this (depending on what you really need) is to construct a /10 signal, delay it by 2.5 cycles (using a neg-triggered FF) and XOR it with the undelayed version. If the freq. of the input is high enough to allow you to use the on-chip DLL (if you're using an FPGA with one), many DLLs will do a divide-by-5. JakeArticle: 72685
"mep" <mpe@metanic.dk> wrote in message news:4130c30c$0$287$edfadb0f@dread14.news.tele.dk... > Hi Andrew > In real hardware the trick is to use a 5-stage shift register with an > inverter between the output of the last stage and the input of the first > stage. This should be easy to implement in VHDL. > Mogens Pelle > Mogens - That gives you a /10, not /5 (assuming you start with all 5 FFs in the same state). But he could use your 5-stage shift register + inverter if he initialized it to "00011". Then delay the shift register output (any stage will work) 1/2 cycle and OR it with the undelayed output to create a 50% duty cycle /5 clock. Without a 2x clock I don't think there's any way to avoid a 1/2 cycle delay someplace plus a gate. Another poster (Jake) suggested a /10 signal delayed 2 1/2 cycles then XORed with the undelayed output. Same idea. RJSArticle: 72686
Mike Treseler <mike_treseler@comcast.net> wrote in message > > *Simulation* is an alternative to logic analysis. > For synchronous designs, a functional sim and > Xilinx static timing are all the chipscope you need. (Mike, I generally respect your posts, this one bears comment) If this were true, Chipscope would probably not exist. Let's hypothesize some numbers (someone with better knowledge of simulator performance please correct me on the first point) 1) A simulator (even a cycle based one) on a moderately complex design may run about 10e5 times slower than the actual circuit. E.g., a 100 MHz FPGA might simulate at about 1 KHz, 1 ms/cycle. This number is just a crude estimate, assumes 10e4 nodes in a circuit, 10e2 cycles per node processing time for the simulator, and the simulator cycling a 1 GHz. (I think this is optimistic, does anyone have a good number?) 2) State machines can be extremely complex, with "billions _of_ billions" of states. Remember, a processor executing code is really a state machine, where state corresponds to [program counter, register contents, pipeline states, even memory contents]. For that matter, the whole FPGA can be viewed as a single state machine...but I won't get that outrageous. Assume three state machines, A, B and C (each of which has already been thoroughly proven) each with only 10000 states each (tiny pieces of code running on simple processors, with very few variables perhaps), and a set of 10 external inputs. Further assume that an error condition corresponds to a small subset of the trillions of possible states (bit x of variable X on processor A is '1' while bit y of variable Y on processor B is '0' and bit z of variable Z in processor C is '0', causing the rocket engine to shut down or whatever). Now make the biggest, wildest assumptions of all: 3) A totally brilliant (omniscient?) test bench writer produces code that puts the system through every possible state. (Unlikely, but possible...there are some smart people out there), and produces this code in under a month. 4) Each of the 10e12 states of the hypothetical machine can be reached in a single simulator cycle (even more unlikely than 3). So we have: 10e12 states at 10e-3 seconds per state giving 10e9 seconds to perform the simulation... umm, that's 31.7 years. Meanwhile, a day of testing the actual circuit on the testbed turns up the failure. OK, I hear sputtering on comp.arch.fpga...from both sides... "Someone didn't do enough higher level system analysis, the system designer should be shot" "It's the programmer's fault, shoot him" "Only 10e12 states? I've got 50 different inputs to worry about, let alone internal states. Shoot me" So shoot down my example, you can probably come up with a better one. The point is (echoing Jeff Goldlum, "Jurassic Park" ran last week) any sufficiently complex system will have unforseen failure modes. Simulation (even "formal verification") cannot catch them. When the failure occurs, it is nice to have visibility into the circuit, be it Chipscope or handrolled test circuitry. Forget about Brian's BlockRAM example, Mike's arbitration answer takes care of that. Here where I work, programmers tend to use logic analysis as much as the H/W types do, to monitor bus activity (who said what to whom, and when?). My designs involve video processing, which can be quicker to implement and look at than to try to simulate. If I understand O.P., he's in the same position. To all c.a.f, sorry for the B/W, I haven't posted anything lately. I just hate hearing "simulation is all you need". For small simple circuits that is true; for larger systems, the more tools the better (till you end up spending more time learning the tools than actually producing). Apologies Mike if I took your statement out of context. You are 100% right about regression, but not every corner can be forseen, and often the data outweighs the simulator. I don't use timing sim either (although the x-men posts leave me wondering if I'll have to)... Regards, JohnArticle: 72687
I know this. For reasons I dont want to get into I cant use EDK. so i wanted to compile with a mostly standard gnu tool chain install. Thanks Matt On Fri, 27 Aug 2004, Peter Ryser wrote: > EDK ships with GNU tools. > > - Peter > > > Matthew E Rosenthal wrote: >> Has anybody out there had any luck using GNU tools to compile source code >> into an ELF file that can be loaded into an ISE or EDK project? >> >> is it possible? easy? >> >> Thanks >> >> Matt > >Article: 72688
Hey Guys, I have this "development Suite" and am wondering if it is worth anything, I'd like to sell it. If it isn't I'd like to know which deserving group I should donate it to. Thanks for any comments. * Nios Embedded Processor, Documentation and Reference Designs * Nios development Board - Stratix EP1S10 Device - One 10/100 Ethernet and One CompactFlash Connector - Two RS-232 Ports - 1-Mbyte SRAM, 16-Mbyte Single-Data Rate (SDR) SDRAM and 8-Mbyte Flash Memory - Mictor Trace/Debug Connector and Expansion Prototype Headers * Quartus II Design Software with SOPC Builder System Development Tool * GNUPro Toolkit: Software Development Suite * Power Supply and CablesArticle: 72689
Jonathan Bromley wrote:
> Most people fake their way around this by replacing the first
> FF model in the resynchroniser with a FF model that doesn't
> propagate X.
Another way is to have the testbench
fake synchronized stimulus for the
"unsynchronized" inputs.
This allows a functional test of the
untainted synthesis code or netlist.
-- Mike Treseler
Article: 72690John wrote: > Mike Treseler <mike_treseler@comcast.net> wrote in message > >> *Simulation* is an alternative to logic analysis. >> For synchronous designs, a functional sim and >> Xilinx static timing are all the chipscope you need. > (Mike, I generally respect your posts, this one bears comment) Yes, it is a bit overweening. Maybe I should have said: For synchronous designs, a functional sim and static timing can cover at least as much ground as logic analysis. > If this were true, Chipscope would probably not exist. Chipscope exists because a significant percentage of fpga designers already understand and can make good use of logic analysis to debug designs. > So we have: 10e12 states at 10e-3 seconds per state giving 10e9 > seconds to perform the simulation... umm, that's 31.7 years. > Meanwhile, a day of testing the actual circuit on the testbed turns up > the failure. > > OK, I hear sputtering on comp.arch.fpga...from both sides... No sputtering here. Simulation can't cover every fpga code defect. Certainly testing continues on the bench and at alpha and beta sites. And almost certainly, the fpga designer will be fingered with a defect or two. When this happens, you either fire up a sim and try duplicate the problem or configure a logic analyzer and try and trigger on it. It's a matter of personal preference. When you're under the gun, you go with what you know best. > To all c.a.f, sorry for the B/W, I haven't posted anything lately. I > just hate hearing "simulation is all you need". If that's how it sounded to you, I apologize. My intention was to voice the minority opinion that simulation can be just as useful as logic analysis. Thanks for the posting. -- Mike TreselerArticle: 72691
Hi ! we are wrapping some of our IP Cores for EDK. That way they can be automatically instantiated in to a SoC and easily integrated. However, we seem to have problems with include files. Our cores are written in Verilog, and we don't know how to specify the proper include path for include files. When EDK compiles the IP Core it can not find the include files unless we manually copy them to a local working directory. Does anybody know how to solve this problem ? Thanks, rudi ============================================================= Rudolf Usselmann, ASICS World Services, http://www.asics.ws Your Partner for IP Cores, Design, Verification and SynthesisArticle: 72692
Brian, Actually i mean if d is input port and data is coming to it at double data rate. in my code q1 and q2 are signals which takes data from d on risng and falling edges respectivley. ie. data in d on rising edge of clk shud come to q1(on falling edge of clk) and similarly data in d on falling edge of clk shud come to q2(on next rising edge of clk). timing diagram for input DDR is shown in this link.. page no : 225 http://direct.xilinx.com/bvdocs/userguides/ug002.pdf i am getting functional simulation correct but not gate level.. ie. data in d on rising edge of clk getting to q1 on same rising edge itself.similarly for q2. i think u can once simulate it and check it.. thank you vinod Brian Philofsky <brian.philofsky@no_xilinx_spam.com> wrote in message news:<cgnl64$d3i2@xco-news.xilinx.com>... > Vinod, > > I do not fully understand your problem but I can guess that you may > be having issues with order of events in the simulator other than what > you are expecting. Try to offset your input stimulus from the clock so > that the two do not happen at the same time to see if that makes things > clearer as to how the logic operates. In other words try changing your > input stimulus to change 1 ns after the clock edge and see if the > results look more as you would expect. > > > -- Brian > > > vinod wrote: > > > Brian Philofsky, > > Thank u for ur response..i made changes in my stimulus as u told > > stimuli : process > > begin > > wait for 20 ns; > > reset <= '1'; > > > > wait for 120 ns; > > reset <= '0'; > > > > > > > > wait; > > end process stimuli; > > and i made simulation once again but @180 ns the rising edge data '0' > > of d comes to q1 in same rising edge ..actually it shud come at > > falling edge.. it is correct in functional simulation... i am getting > > same wrong result even if I used IFFDDRSE primitive . > > > > can u check this plz.. > > > > thank u > > vinod > > > > > > Brian Philofsky <brian.philofsky@no_xilinx_spam.com> wrote in message news:<412E568B.9020503@no_xilinx_spam.com>... > > > >>Vinod, > >> > >>I would guess that the reason you are seeing a functional difference > >>would be due to the fact that you are not waiting until the global > >>set/reset signal to complete. For all Xilinx gate-level simulations, a > >>global set/reset pulse is generated for the first 100 ns of the design > >>to initialize all of the registers and simulate the effect for the GSR > >>signal in simulation. For the first 100 ns of the design, the registers > >>will be in reset and will not change value. If you hold off you > >>stimulus for the first 100 ns of simulation (keep your clock running and > >>initialize the inputs but just don't wiggle them yet), you will likely > >>see more correlation between your behavioral and post-translate simulation. > >> > >>Also, if you are desiring to have the DDR register pulled into the I/O > >>and use the dedicated resource, you should be instantiating the IFDDRRSE > >>in the design. The code you are creating will use two separate > >>registers but not the dedicated DDR registers in the I/O. > >> > >> > >>-- Brian > >> > >> > >>vinod wrote: > >> > >> > >>>i am vinod..i got problem with ddr for virtex2 fpga. i have written > >>>code and did functional simulation everything is correct but after > >>>post translate simulation i am not getting same result. here is my > >>>code and testbench > >>> > >>>code: > >>>library ieee; > >>>use ieee.std_logic_1164.all; > >>>library UNISIM; > >>>use UNISIM.VCOMPONENTS.ALL; > >>> > >>>entity input_ddr is > >>>Port ( d : in std_logic; > >>>reset : in std_logic; > >>>clk : in std_logic; > >>>dataoutx : out std_logic; > >>>dataouty : out std_logic > >>> ); > >>>end input_ddr; > >>> > >>>architecture input_ddr_arch of input_ddr is > >>> > >>> > >>>signal q1, q2 : std_logic; > >>> > >>> > >>> > >>>begin > >>> > >>> > >>> > >>> > >>>process (clk,d,reset) > >>>begin > >>> > >>>if reset = '1' then > >>> q1 <= '0'; > >>> dataoutx <= '0'; > >>> > >>>elsif rising_edge(clk) then > >>>q1 <= d; > >>>dataoutx <= q1; > >>>end if; > >>>end process; > >>> > >>>process (clk,d,reset) > >>>begin > >>>if reset = '1' then > >>> q2 <= '0'; > >>> dataouty <= '0'; > >>>elsif falling_edge(clk) then > >>>q2 <= d; > >>>dataouty <= q2; > >>>end if; > >>>end process; > >>> > >>> > >>> > >>>end input_ddr_arch; > >>> > >>>testbench.... > >>>library ieee; > >>>use ieee.std_logic_1164.all; library ieee; > >>>use ieee.std_logic_1164.all; > >>>use ieee.numeric_std.all; > >>>use IEEE.STD_LOGIC_1164.ALL; > >>>use IEEE.STD_LOGIC_ARITH.ALL; > >>>use IEEE.STD_LOGIC_UNSIGNED.ALL; > >>>library UNISIM; > >>>use UNISIM.VCOMPONENTS.ALL; > >>> > >>>entity tbddr is > >>>end entity tbddr; > >>> > >>>architecture test2 of tbddr is > >>>component input_ddr is > >>>Port ( d : in std_logic; > >>>reset : in std_logic; > >>>clk : in std_logic; > >>>dataoutx : out std_logic; > >>>dataouty : out std_logic > >>> ); > >>>end component ; > >>> > >>> > >>>component FDDRRSE is > >>>port ( > >>> > >>>Q : out STD_ULOGIC; > >>>C0 : IN STD_ULOGIC; > >>>C1 : IN STD_ULOGIC; > >>>CE :IN STD_ULOGIC; > >>>D0 : IN STD_ULOGIC; > >>>D1 : IN STD_ULOGIC; > >>>R :IN STD_ULOGIC ; > >>>S : IN STD_ULOGIC > >>>); > >>>end component; > >>> > >>> > >>> > >>>signal risdatax,faldatax : std_ulogic; > >>>signal dataoutx,dataouty : std_logic; > >>>signal count : natural range 0 to 15; > >>>--signal cnt : natural range 0 to 40; > >>>signal ind : std_logic; > >>>signal S,R,cE :std_logic; > >>> > >>>signal data : std_ulogic_vector(15 downto 0):="1101000111010101"; > >>>signal data1 : std_ulogic_vector(15 downto 0):= "1001011100011100"; > >>>--signal data2: std_ulogic_vector(15 downto 0):= "0010100111001011"; > >>>signal clk,invclk, reset :std_logic; > >>>signal clk2 ,d : std_logic; > >>>begin > >>> > >>>--clk2 <= not clk; > >>> > >>> > >>>uut1: input_ddr > >>>port map ( > >>> d => d, > >>> clk => clk, > >>>reset => reset, > >>>dataoutx => dataoutx, > >>>dataouty => dataouty > >>> > >>> > >>>); > >>> > >>> > >>>FDDRRSEx : FDDRRSE > >>>port map ( > >>> > >>>Q => d, > >>>C0 => clk, > >>>c1 => invclk, > >>>CE => ce, > >>> > >>>d0 => risdatax, > >>>d1 => faldatax, > >>>r => '0', > >>>s => '0' > >>>); > >>> > >>> > >>> > >>>clock1 : process > >>>begin > >>> clk <= '1'; > >>> invclk <= '0'; > >>>wait for 10 ns; > >>> > >>>clk <= '0'; > >>>invclk <= '1'; > >>>wait for 10 ns; > >>>end process; > >>> > >>>stimuli : process > >>>begin > >>>wait for 20 ns; > >>>reset <= '1'; > >>> > >>>wait for 40 ns; > >>>reset <= '0'; > >>> > >>> > >>> > >>>wait; > >>>end process stimuli; > >>> > >>>process(clk,reset,ind) > >>>begin > >>> if reset = '1' then > >>> count <= 0; > >>> ce <= '0'; > >>> risdatax <= '0'; > >>> faldatax <= '0'; > >>>elsif clk'event and clk = '1' then > >>> > >>> ce <= '1'; > >>> risdatax <= data(count); > >>> faldatax <= data1(count); > >>> if count < 15 then > >>> count <= count+1; > >>> elsif count = 15 then > >>> count <= 0; > >>> end if; > >>> end if; > >>> > >>> end process; > >>>end test2; > >>> > >>> > >>> > >>>i have used FFDDRSE primitive in testbench for generating double data > >>>rate. > >>> > >>>i will be waiting for reply... > >>> > >>>thanks in advance > >>>byeArticle: 72693
On Fri, 27 Aug 2004 22:25:38 GMT, Simon <news@gornall.net> wrote:
>>> Someone wrote:
>>>
>>> Actually in the newer BlockRAM implementations, you can choose the
>>> behaviour (at least you can on the Spartan-3, whose datasheets I've
>>> been poring over recently :-)
>>>
>>> There's:
>>>
>>> o READ_FIRST, which will always report the value of the data
>>> in RAM before the write was committed
Which means: If you write to Port A, at address Y, with data Z,
the prior contents of location Y will be latched on the port A
output. Location Y will be set to Z.
If Port B is looking at some address other than Y, the behavior
is as expected. If port B is set to address Y, and the clocks
occur at the appropriate time, and Port B is enabled, you might
not get what you expect. I describe exactly what happens below.
>>> o WRITE_FIRST, which will provide the unpredictable behaviour
>>> you mention (and it's the default, to provide backwards
>>> compatibility)
Which means: If you write to Port A, at address Y, with data Z,
the Z be latched on the port A output. Location Y will be set to Z.
If Port B is looking at some address other than Y, the behavior
is as expected. If port B is set to address Y, and the clocks
occur at the appropriate time, and Port B is enabled, you might
not get what you expect. I describe exactly what happens below.
>>> o NO_CHANGE, which seems to disconnect the output RAM so the
>>> output value remains unchanged.
Which means: If you write to Port A, at address Y, with data Z,
Location Y will be set to Z. Port A output latch will not be changed.
If Port B is looking at some address other than Y, the behavior
is as expected. If port B is set to address Y, and the clocks
occur at the appropriate time, and Port B is enabled, you might
not get what you expect. I describe exactly what happens below.
>>> I doubt anything would help you if you simultaneously write into the
>>> same address on both ports, though :-)
This is called "you get what you deserve mode"
>> Brian Philofsky wrote:
>> This is a mis-conception many fall into. Those modes apply only to the
>> port that is being written to. In other words, the output of the port
>> being written has this known behavior you specify above but as for the
>> other port, everything I said still applies regardless of which mode you
>> have it in.
I believe this is not quite the full story. The write mode causes some
changes in the internal timing sequence of a port, and when exactly the
RAM is updated. The write mode on the other port has no affect on the timing
of a read on that port. The following describes how the internal timing
sequence on the write port can affect the read on the other port, IF it is
using exactly the same clock, enable, and address.
>Hmm, well XAPP463 (Using BlockRAM in spartan3 FPGA's) seems to cope with
>both ports, or am I misunderstanding what you are saying ?
The problem is that this APP note does not express reality well.
>I'm looking at the table (table 8) on page 14, and it's laid out as:
>
> Write mode Same Port Other port (dual port only, same addr)
>-------------------------------------------------------------------
> WRITE_FIRST blah Invalidates data on DO,DOP
> READ_FIRST blah Data from RAM to DO,DOP
> NO_CHANGE blah Invalidates data on DO,DOP
>
>
>I thought it was clear, but now I'm confused :-(
I hope the following will un-confuse you, and give you understanding.
Here is the "truth"
1) The two ports are totally independent, except for the array
of storage bits.
2) There is no contention detection logic, or address match logic. So
there is no way for the block RAM to "know" that both ports are
accessing the same location.
3) The 3 different write modes do not have identical internal timing
and this leads to behavior that may surprise you if you didn't
know this.
4) If the two clocks are asynchronous, you can not predict what will
happen on the other port, when writes and reads are close to each
other, and addresses match. If you care about reliable systems,
there should be system level things you should have done so that
this can never occur.
So what follows, is for the very special case of:
A) both ports are using the same clock
(if not, nothing can be predicted)
B) both ports are enabled
(if the non writing port is not enabled, then nothing changes
on its output regardless of address. Remember, the ports are
totally independent)
C) port A is writing, port B is reading (or the other way round)
(if neither are writing, then nothing special is going on.
if both are writing, either it is to different address
and nothing special about that, or they are writing to the
same address, and you need a new system designer)
D) both ports have the same address
(if not same address, nothing special to think about)
Block RAMS take time to write data. Block RAMS take time to read
data. Reading and writing involves address decoding, data propagation,
write select lines, sense amplifiers for reading, timing control logic.
To write, latch the address, data, enable. Decode address, select the
word, distribute the data on the bit lines, strobe the word write logic.
To read, latch address, enable. Decode address, select the word,
enable contents to be driven from the RAM bits onto the bit lines, use
the sense amps to read the bit lines, latch the sensed data into the
output latch.
Between read and write, the address latch and decode logic is obviously
shared, and that is not an issue because the reads and writes use them
the same way. The bit lines are a different story.
Here is the timeline for Read and the 3 write modes:
READ: decode address, drive RAM onto bit lines, use sense amps
to read bit lines, update output latch.
WRITE_FIRST: decode address, distribute write data, strobe data into RAM
drive RAM onto bit lines (no change), use sense amps
to read bit lines, update output latch.
READ_FIRST: decode address, drive RAM onto bit lines, use sense amps
to read bit lines, update output latch, distribute write
data, strobe data into RAM
NO_CHANGE: decode address, distribute write data, strobe data into RAM
READ and READ_FIRST have the same read timing. The read timing for
WRITE_FIRST is different.
WRITE_FIRST and NO_CHANGE have the same write timing. The write timing
for READ_FIRST is different.
Now lets look at the table 8 from the APP note, but first, lets look at
the prior paragraph:
"These different modes determine which data is available on the output
latches after a valid write clock edge to the same port."
underline "same port"
"In READ_FIRST mode, a memory port supports simultaneous read and write
operations to the same address on the same clock edge, free of any
timing complications."
Place a little asterisk after "free of any timing complications".
At the bottom of the page, put another asterisx, and follow it with a
link to this article.
"Table 8 outlines how the WRITE_MODE setting affects the output data
latches on the same port, and how it affects the output latches on the
opposite port during a simultaneous access to the same address."
underline "during a simultaneous access". This means: Exactly the same
clock, and enable. Go back and read (4) above.
OK, here we go.
>I'm looking at the table (table 8) on page 14, and it's laid out as:
>
> Write mode Same Port Other port (dual port only, same addr)
>-------------------------------------------------------------------
> WRITE_FIRST blah Invalidates data on DO,DOP
Port A writes, port B reads same address, identical clocks.
port B is using READ timing (see above) which assumes that RAM contents
are stable. WRITE_FIRST is writing to the RAM at this time, so bits are
in transition. Port B sees anything between old contents, new contents,
or a mix of both. The read and write timing are "self timed" so no
predictions can be made as to which happens first. Rather than say
"Invalidates" it would have been better to say "unpredictable"
> READ_FIRST blah Data from RAM to DO,DOP
Port A does the late write, so the port A read first occurs at the same
time as the port B read, so the data has not yet changed at the time
when port B is reading, so it gets the old contents, same as port A.
> NO_CHANGE blah Invalidates data on DO,DOP
Port A writes, port B reads same address, identical clocks.
port B is using READ timing (see above) which assumes that RAM contents
are stable. NO_CHANGE is writing to the RAM at this time, so bits are
in transition. Port B sees anything between old contents, new contents,
or a mix of both. The read and write timing are "self timed" so no
predictions can be made as to which happens first. Rather than say
"Invalidates" it would have been better to say "unpredictable"
You can see all the gory details by going to http://patft.uspto.gov
and looking at US 6,373,779
"Block RAM having multiple configurable write modes for use in a
field programmable gate array "
Figure 5 is READ
Figure 6 is WRITE_FIRST
Figure 7 is NO_CHANGE
Figure 8 is READ_FIRST
This will be on the final exam.
Philip Freidin
===================
Philip Freidin
philip.freidin@fpga-faq.com
Host for WWW.FPGA-FAQ.COM
Article: 72694Hi Matthew, Matthew E Rosenthal wrote: > I know this. > For reasons I dont want to get into I cant use EDK. so i wanted to > compile with a mostly standard gnu tool chain install. I recently used Dan Kegel's crosstool to build a power PC toolchain, then used that tool chain to build a PPC linux kernel targeted for a V2Pro device. Alas I don't have a dev board to test it (ml300 reference platform), but the initial signs were good. The ppc compiler distributed with edk is gcc-powerpc-eabi - it should be easy to use crosstool to build this toolchain. I don't have enough experience with the V2Pro PPC core to say if there are any special tricks in the EDK version. Regards, JohnArticle: 72695
Hi Rudi, Rudolf Usselmann wrote: > we are wrapping some of our IP Cores for EDK. That way they > can be automatically instantiated in to a SoC and easily > integrated. Good plan! I would love to see a wishbone -> opb bridge to get some of that great opencores.org stuff into microblaze projects. > However, we seem to have problems with include files. Our > cores are written in Verilog, and we don't know how to > specify the proper include path for include files. When > EDK compiles the IP Core it can not find the include files > unless we manually copy them to a local working directory. > > Does anybody know how to solve this problem ? Maybe the .pao (peripheral analyse order) file has something to do with it? It lives in pcores/mycore/data/... I've only used it for VHDL cores, but it probably has a role to play with verilog as well. Hope this hepls, JohnArticle: 72696
Philip Freidin wrote: > > On Fri, 27 Aug 2004 22:25:38 GMT, Simon <news@gornall.net> wrote: >> >>I thought it was clear, but now I'm confused :-( > > > I hope the following will un-confuse you, and give you understanding. Thanks Philip, most illuminating :-) > This will be on the final exam. [grin] I did my finals more years ago than I care to remember, but I'm always keen to learn something new :-) [aside] Up until now I've always used single-clock designs, so there was an implicit assumption in my post that the clocks/enables were identical on both ports. It's the signs down the multiple-clock path that put me off, you know, the ones saying "Abandon hope, all ye who enter here", and "Here be Dragons". I think the blood dripping onto the path is a little melodramatic though :-) [/aside] Simon.Article: 72697
I noticed that there's the capability in the floorplanner to create an RPM from a floorplanned design. I tried floorplanning some of the lower-level modules, and then saving them into the [module].ucf file, but the higher-level modules (those that instantiate the lower ones :-) didn't seem to pick up on the RPM availability. Is there something I have to do in the high-level module to tell ISE to use the RPM ? I'm using verilog and XST if that matters ? Cheers, Simon.Article: 72698
ted wrote: > Hi, > > Does anyone know if it's possible to run the Xilinx ISE 4.2i software in > Linux? I would like to develop VHDL code and then program my FPGA (I use a > parallel port JTAG programmer). Being able to do this from Linux would make > the project easier as I need to develop a Linux device driver at the same > time. I was thinking I could use WINE. Do any websites with instructions > exist? > > Thanks. > > Hi Programming the actual FPGA using JTAGcannot be done from within the ISE - you need to find a third-party program to do that under linux, but at least ISE 6.x will run under Wine otherwise (mostly). See my page on how to do it here: http://www.danbbs.dk/~kibria/xilinx.html I don't know if this applies fro 4.2 also - but you can always give it a try. Hope it helps. -- BrianArticle: 72699
"Rudolf Usselmann" <russelmann@hotmail.com> wrote in message news:cgpi22$lkk$1@nobel.pacific.net.sg... > Stephen Williams wrote: > >> Brad Smallridge wrote: >>> Maybe it's one of those spaces in the path names problems disguised as >>> path too long. >> >> Might be. >> >> Have I mentioned yet that I hate this Wind/U atrocity?-) >> > > I have to jump in here ! > > This Wind/U crap is made by some sort of a third party, to > "easy" "porting" of windows applications to unix like systems. > > I can't see the usability of any GIUs made with this Wind/U > stuff. Did anybody try to use EDK on Linux ? C'mon, I am > trying to get a job done not finding out alternative ways > to use a mouse and a keyboard. > > Great to see the results from the Wind/U "porting" tools. > Don't have to bother evaluating or trying it out for any > of our projects - what a piece of crap !!! > > If Xilinx could find an alternative to this Wind/U, I think > they would have an excellent tool flow for Linux (plus fixing > the paralle port support to something native of course). > Well if they ever need a cross platform gui they should look at wxwidget (was wxwindows ) http://www.wxwindows.org/ available for windows , linux and mac ox as well as support for x, gtk+ , motif for some screenshots follow the links http://www.wxwindows.org/screensh.htm for a list of users which includes AMD , AOL , Green Mountain(VHDL Studio), ING (Bank), Lockheed Martin, Ecos, Scitech , Xerox and others http://www.wxwindows.org/users.htm for a list of applications writen using it http://www.wxwindows.org/apps.htm wxperl http://wxperl.sourceforge.net/ wxpython http://wxpython.org are bindings for those languages Probably take a bit / while to rewrite but to have one common main project would make it easier to support multiple platforms. Alex
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