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
Ray Andraka <ray@andraka.com> wrote in message news:<3C69B198.C52EA024@andraka.com>... > Like I said, that is the speed of the routing. [...] Sure, I took notice (as I said, I will probably interleave two LFSR as the FF only implementation takes too many CLB). I just did a quick hack to ascertain that the extra delay was really coming from routing. Of course I'll need to do this optimization again when I've settled on an LFSR polynomial (downloaded XAPP052 a few days ago, still waiting for time to read it). > Xilinx: Perhaps a good thing to do would be to add a note in the timing reports when the > period constraint on a clock that clocks an SRL16 is less than the minimum period dictated > by the min pulse widths. Same for the minimum and maximum clocks for the clkdlls. > Several people I am aware of have missed these limitations in recent designs. I second that. I would have fallen into that trap and been burned quite badly. Especially worrysome is that with default settings the synthesis will automatically infer SRL16 for shift registers that the user might think should have been instantiated as FF chains. I wonder if it would be possible to "fix" that by a timing constraint. Is it possible to put constraints on all instances of some particular primitive (that is invisible to the original HDL nonetheless) instead of on specific nets? > Std_logic_unsigned and std_logic_signed were synopsis libraries. They generally cannot > coexist in the same entity because they have conflicting declarations. Despite the name, > they are also not standard among different vendors. For the assignments, you can use > casts for related types. Std_logic_vector, unsigned, and signed are related types so; > Numeric_std is an IEEE standard library. Us it instead of wrestling with all the problems > of std_logic_unsigned, std_logic_arith and std_logic_signed. > > slv_signal<= std_logic_vector(unsigned_signal); > unsigned_signal<= unsigned(slv_signal); > > Does that answer your question? Not fully. I get errors for constructs like: unsigned_signal <= 0; -- compiler wants bitstring for literal unsigned_signal <= unsigned(0); -- compiler: can not be converted to unsigned These must have a simple solution, as for instance unsigned_signal <= unsigned_signal*0; -- works like a charm doesn't pose any problems. Achim Gratz.Article: 39551
Ray Andraka <ray@andraka.com> wrote: > I just tried using the 4.1 sp3 floorplanner for a Virtex (QPRO) design which has > a bunch of RPMs with RLOCs in the code. What a disaster. The new floorplanner > is badly screwing up the RLOC'd placement...it looks like maybe it thinks it is > trying to place a virtexII. I tried reading an FNF from a 3.3 design, that gets I haven't seen this, but I did notice another problem; I placed some RPMs (RLOCs in VHDL) with the Floorplanner, for a Virtex-II, and in the UCF file created, the X and Y co-ordinates were swapped! Hamish -- Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>Article: 39552
Ray Andraka <ray@andraka.com> wrote: > My thoughts are that Xilinx ought to make the updated timing files available for 3.3 > immediately so that people using floorplanner with RPMs aren't in a pickle (do people > really use floorplanner without RPMs? How tedious can that be?) I use it mostly to: 1. inspect the work of the auto-placer, and 2. generate area groups to assist the auto-placer. Having said that, my last week or two of attempting to route a couple of ambitious Virtex-E designs have made me place more and more logic with fixed LOCs rather than area groups. Area groups are a big help but there's still enough rope for PAR to hang itself. 4.1i in a Virtex-II is a dream to work with, though (at the same clock speed). 3.1i in Virtex-E is hell for me lately. Hamish -- Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>Article: 39553
I want to use a CLKDLL without BUFG with a 33% duty-cycle clock. I have the good Duty Cycle Correction Property in the DLL, but I have the same duty-cycle after and before the DLL.Article: 39554
Dinesh <dineshb@ctd.hcltech.com> wrote: > 1. What is the significance of CALENDAR_M. How does this value is > determined? > 2. Why do we have to iterate the calendar sequence for CALENDAR_M > times? > 3. If the calendar_M is set to a large value, how does it impact? From memory, the receiver sends the sequence of length CALENDAR_LEN, CALENDAR_M times between control words. That is, there will be CALENDAR_LEN * CALENDAR_M status bytes transferred, followed by the DIP2 parity word, followed by the framing word, then the sequence repeats. The transmitter and receiver have to agree on the value of CALENDAR_LEN and CALENDAR_M for the status bus to frame up. CALENDAR_LEN may be fixed by the number of ports supported by your devices but CALENDAR_M is usually configurable. Increasing CALENDAR_M just decreases the amount of overhead on the status bus. It also changes the probability of detecting a parity error on the bus. Probably you would set CALENDAR_M to the largest value supported by your transmitter or receiver. > 4. The data transmitter will transmit data based on the FIFO status. > Based on which FIFO status it will transmit whether based on the first > iteration or last iteration(calendar_m)? I would think that you would use the most recent value you have received. I'm curious as to your application? regards, Hamish -- Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>Article: 39555
Had the same problem,zero feedback and did this : Installed Paintshop pro and captured the schematics :-) I know it is the solution of the dumb but at least it worked :-)Article: 39556
Ray Andraka <ray@andraka.com> wrote in message news:<3C69C149.CDEC9B51@andraka.com>... > Without a second processor doing other tasks is extremely sluggish, and running a short > sim or synthesis run while a place and route is in progress (for example) is out of the > question. The second processor doesn't speed up any of the EDA tools that I am aware of. > The difference is that I can do reasonable work (not just text edits) while I've got > something else running. To make it at all useful, you've got to load the machine up with > memory so that it isn't paging a lot, and you should have some good fast storage. I have > a dual PIII-800e and a single PIII833 here. I'll take the dual any day over the single > because I'm not left sitting on my hands while a sim runs. > A fast dual processor is great to have. I used a 800 MHz dual PIII, and while one processor was pegged doing a Place and Route, I was able to listen to MP3 tunes and surf the net using the other processor, without a single glitch heard from the MP3 player! :) But speaking on the single threaded aspect of a lot of EDA software, last I looked, dual processor clock speeds tend to lag behind single processor clock speeds, and I think I am better off buying a reasonably priced single processor computer every year, and use one of those keyboard/mouse/video switch boxes to do other things on the old computer while doing a place and route on my greatest and newest computer. This strategy also allowed me to justify the purchase of an AMD XP system, which made me happy because I own AMD stock. NewmanArticle: 39557
Thanks John. Everything is working fine now.Article: 39558
You can put it out as an edif netlist. That can be blackboxed into any design
flow. It would be helpful if you could put a simulation model with it.
Nicholas Weaver wrote:
> I have a nice Rijndael encoder implementation for the Spartan
> II/Virtex FPGAs (over 1 Gbps, 115 MHz, <800 clb slices, fully key
> agile, Spartan II-100-5 (according to static timing analysis)). Once
> I get the last minor interfacing bug squished, I'll release it under
> the LGPL.
>
> The question is, is there a more convenient way than it's current form
> (a Foundation/aldec schematic design, consisting of about 5-6
> schematic specified RLOCed blocks which are placed with RLOC_ORIGINs)
> to release it instead of just the schematics? EG, a nice way to turn
> the schematic pieces into a more portable modules? Some RLOCing is
> needed to specify the design to a specific chip (to balance delays
> between blockrams and to place the subkey generation in the
> appropriate place, and to tile to larger bandwidth).
> --
> Nicholas C. Weaver nweaver@cs.berkeley.edu
--
--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: 39560
for 4K deep, it should be using 12 BRAMs arranged as 4Kx1 bit slices.
Just verify that it is doing that and not something silly with muxes. The
XCV***-4 parts' BRAM maxes out at about 125 MHz, but to get there you need
to put pipeline registers immediately before and after all the signals in
and out of the RAM. The worst timing is on the ENA and WE inputs. These
two really need a duplicated flip-flop driving them and located
immediately adjacent to the BRAM (1 FF per BRAM). Check your timing reprot
for the worst case paths. dollars to donuts the WE and/or ENA paths are
among the worst. Also, you should probably duplicate the address
generators, especially if you have not located all the RAMs close
together. One last thing, the automatic place and route does a lousy job
at placing the BRAMs, use the floorplanner to place the RAMs close
together and to place the pipeline registers adjacent to the BRAMs.
Antonio wrote:
> Good Morning, the speed of my project is all depending on the speed of
> the RAM I use in it, I need a RAM 3072x12, to obtain it I used CORE
> GENERATOR , choose single port RAM version 3.0 arranged for VIRTEX (in
> my case I use XCV1000BG560-4) but the speed is really low, a maximum
> of 50MHz and I repeat the speed of my circuit is only depending on the
> RAM that can be read only (Essentially it is a ROM) and must be read
> on every negative front of the clock. Can you tell me the setting I've
> to do for this core to obtain the maximum speed ??
> I've choose a dimension of 4096x12 , thinks this help for the speed.
>
> Thanks Antonio
--
--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: 39561
Achim Gratz wrote:
> Ray Andraka <ray@andraka.com> wrote in message news:<3C69B198.C52EA024@andraka.com>...
> > Like I said, that is the speed of the routing. [...]
>
> Sure, I took notice (as I said, I will probably interleave two LFSR as
> the FF only implementation takes too many CLB). I just did a quick
> hack to ascertain that the extra delay was really coming from routing.
> Of course I'll need to do this optimization again when I've settled on
> an LFSR polynomial (downloaded XAPP052 a few days ago, still waiting
> for time to read it).
>
> > Xilinx: Perhaps a good thing to do would be to add a note in the timing reports when the
> > period constraint on a clock that clocks an SRL16 is less than the minimum period dictated
> > by the min pulse widths. Same for the minimum and maximum clocks for the clkdlls.
> > Several people I am aware of have missed these limitations in recent designs.
>
> I second that. I would have fallen into that trap and been burned
> quite badly. Especially worrysome is that with default settings the
> synthesis will automatically infer SRL16 for shift registers that the
> user might think should have been instantiated as FF chains. I wonder
> if it would be possible to "fix" that by a timing constraint. Is it
> possible to put constraints on all instances of some particular
> primitive (that is invisible to the original HDL nonetheless) instead
> of on specific nets?
Problem is the xilinx tools will not change a netlist consisting of only primitives. The fix
has to be in the synthesis tool so that it instantiates FF's instead of SRL16s. You can force
the issue by putting a reset on your shift register, since the SRL16 has no reset. I think
there may be a syn_register_style attribute in some tools that can be used to prevent inference
of an SRL16.
>
>
> > Std_logic_unsigned and std_logic_signed were synopsis libraries. They generally cannot
> > coexist in the same entity because they have conflicting declarations. Despite the name,
> > they are also not standard among different vendors. For the assignments, you can use
> > casts for related types. Std_logic_vector, unsigned, and signed are related types so;
> > Numeric_std is an IEEE standard library. Us it instead of wrestling with all the problems
> > of std_logic_unsigned, std_logic_arith and std_logic_signed.
> >
> > slv_signal<= std_logic_vector(unsigned_signal);
> > unsigned_signal<= unsigned(slv_signal);
> >
> > Does that answer your question?
>
> Not fully. I get errors for constructs like:
>
> unsigned_signal <= 0; -- compiler wants bitstring for
> literal
> unsigned_signal <= unsigned(0); -- compiler: can not be converted to
> unsigned
>
That is because it is expecting a bit vector. Casting only works for closely relted types.
Use the to_unsigned function:
unsigned_signal <= (others=>'0');
unsigned_signal<= to_unsigned(10,bits);
>
> These must have a simple solution, as for instance
>
> unsigned_signal <= unsigned_signal*0; -- works like a charm
>
> doesn't pose any problems.
>
> Achim Gratz.
--
--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: 39562
I've found 4.1 to be just about useless for anything other than VirtexII designs. The
floorplanner is so broken that I can't imagine anyone seriously using it. Xilinx has
acknowledged the carry chain problem with the floorplanner, but there is also a
problem with it changing the placement on other RPMs too. The 'workaround' is to let
PAR run on the unfloorplanned design, constrain from placement, unbind then bind each
RPM. Then you can move it without it getting changed. Unfortunately, the bulk of my
designs are dense enough that PAR can't find a placement, or in cases where it does
there is not enough room to left to move the RPMs where I need them. I also found
that even for a placed design the router in 3.3sp8 does a considerably better job than
the 4.1 router.
Thinking back, I think the tools have lost something on every major release. The 3.x
floorplanner never got to the level the xact floorplanner had reached. It seems that
if it is not necessary for the big green push button flow, it is not a priority.
hamish@cloud.net.au wrote:
> Ray Andraka <ray@andraka.com> wrote:
> > I just tried using the 4.1 sp3 floorplanner for a Virtex (QPRO) design which has
> > a bunch of RPMs with RLOCs in the code. What a disaster. The new floorplanner
> > is badly screwing up the RLOC'd placement...it looks like maybe it thinks it is
> > trying to place a virtexII. I tried reading an FNF from a 3.3 design, that gets
>
> I haven't seen this, but I did notice another problem; I placed some RPMs
> (RLOCs in VHDL) with the Floorplanner, for a Virtex-II, and in the UCF
> file created, the X and Y co-ordinates were swapped!
>
> Hamish
> --
> Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>
--
--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: 39563Just to add to the international flavor of this thread: Some Hungarian: Altera nyomaba se lephet Xilinxnek, legalab ket evvel vannak lemaradva! Some Romanian: Viata e frumoasa...Altera are DSP! :-) Have fun translating it, jakab Austin Lesea <austin.lesea@xilinx.com> wrote in message news:3C6990D5.28C06D67@xilinx.com... > "Kunde passen auf." > > Oder wie sie sagen in Rom: > > Caveat Emptor. > > Austin > > (Ich kann Deutschen lesen, Danke) > > (But excuse my written German, as I am not up to the colloquialisms or > the venarcular) > > > ls_user wrote: > > > Austin: Konkurrenz belebt das Geschaeft. > > > > Please ask Peter for translation. > > > > regards > > > > The Amateur >Article: 39564
I do that occasionally. I have a single processor PIII 833 here that is also loaded up with
RAM. I use it if I have more than one PAR going at a time, or if I expect to be running some
serious sims at the same time as a PAR. It is a little awkward for applications that have
license keys because there is that dongle swapping bit, and there is also the issue of copying
projects back and forth. It is painful enough that I consider it a last resort (plus it means
getting off my fat duff to move back and forth between machines, the other one is in a
different room so others can use it when I am not without disturbing me).
newman wrote:
> A fast dual processor is great to have. I used a 800 MHz dual PIII,
> and while one processor was pegged doing a Place and Route, I was
> able to listen to MP3 tunes and surf the net using the other
> processor, without a single glitch heard from the MP3 player! :)
>
> But speaking on the single threaded aspect of a lot of EDA software,
> last I looked, dual processor clock speeds tend to lag behind single
> processor clock speeds, and I think I am better off buying a
> reasonably priced single processor computer every year, and use one of
> those keyboard/mouse/video switch boxes to do other things on the old
> computer while doing a place and route on my greatest and newest
> computer. This strategy also allowed me to justify the purchase of an
> AMD XP system, which made me happy because I own AMD stock.
>
> Newman
--
--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: 39565
Based on experience (see the par and carry chains not... thread), I'd stick with
3.3 unless you are doing a virtexII design.
Noddy wrote:
> Hi,
>
> Am busy working on a project using Foundation 3.3i, so am hesitant to do any
> software upgrades until the project is complete. I am thus sitting with the
> Xilinx upgrade pack, which Xilinx kindly posted to me, that contains
> software for Foundation 4.1 and ISE 4.1.
> Could someone please give a quick comparison? Which should I be using? Does
> Xilinx see a need for its customers to upgrade to Foundation 4.1 while it is
> trying to market ISE 4.1?
>
> Sorry if this question seems a bit trivial/newbie-ish, but I learn
> everything about FPGA's from this newsgroup.
>
> cheers
>
> adrian
--
--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: 39566I have found while using Leonardo spectrum and Baseline for an Altera design that when I get to 10-15K gates the design leaves bits out of the synthesis. I have had this sort of behaviour with Actel licenses where they have a gate limit. I can't seem to get anyone at Altera or exemplar to be able to tell me absolutely if the free baseline, Leonardo version is gate limited. Does anyone know? Regards LeonArticle: 39567
The availability is for June in Europe (I don't know for North America but I think it is going to be at the same period). So be patient and keep on using Xilinx'stuff!Article: 39568
'life is good', and 'something about how Altera is now behind schedule'? Austin (my father was from Sibu, Romania, and spoke 7 languages. I did not inherit much of his talents, I am afraid) jakab tanko wrote: > Just to add to the international flavor of this thread: > Some Hungarian: > Altera nyomaba se lephet Xilinxnek, legalab ket evvel vannak lemaradva! > Some Romanian: > Viata e frumoasa...Altera are DSP! > :-) > Have fun translating it, > jakab > > Austin Lesea <austin.lesea@xilinx.com> wrote in message > news:3C6990D5.28C06D67@xilinx.com... > > "Kunde passen auf." > > > > Oder wie sie sagen in Rom: > > > > Caveat Emptor. > > > > Austin > > > > (Ich kann Deutschen lesen, Danke) > > > > (But excuse my written German, as I am not up to the colloquialisms or > > the venarcular) > > > > > > ls_user wrote: > > > > > Austin: Konkurrenz belebt das Geschaeft. > > > > > > Please ask Peter for translation. > > > > > > regards > > > > > > The Amateur > >Article: 39569
Jeremy, The DLL requires a BUFG for the best performance. If you use local interconect for the CLKFB and CLK0 routing, the duty cycle won't be nearly as good as using BUFG. BUT, it won't we quite as bad as you are describing. It may be that your IO is not strong enough to faithfully reproduce what is happening inside the FPGA. A good experiment to perform, is to come in on a pin, and then go out on the adjacent pin. The duty cycle distortion you measure there will be pretty small. Then route through a lot of local interconnect to see the difference. Then put in a DLL. etc. etc. If you don't want to use the recommended resources, then you have to become familiar with the performance of less perfect ways of doing the job. The other issue may be that the DLL isn't LOCKED. Always check the LOCKED pin, and try resetting the DLL to see if it suddenly becomes 50/50 duty cycle. WHen clock sources start up, they sometimes exceed the drift or jitter specs of the DLL, and you need to reset again to be sure everything is locked and running. Austin jeremy wrote: > I want to use a CLKDLL without BUFG with a 33% duty-cycle clock. I have the good Duty Cycle Correction Property in the DLL, but I have the same duty-cycle after and before the DLL.Article: 39570
Achim Gratz wrote: > Not fully. I get errors for constructs like: > > unsigned_signal <= 0; > -- compiler wants bitstring for literal numeric_std only covers numeric operations +,-,abs,< etc. between ints and unsigned vectors. Assignments are not overloaded, so the left and right sides must be the same type. > unsigned_signal <= unsigned(0); > -- compiler: can not be converted to unsigned unsigned cast only works on vectors. numeric_std provides a to_unsigned(length,vec) function for this case. > These must have a simple solution, as for instance > > unsigned_signal <= unsigned_signal*0; > -- works like a charm This works because numeric_std overloads the function "*" to return an unsigned vector. It's not much more work to say: unsigned_signal <= (unsigned_signal'range => '0'); -- works like a charm and intent is clear. -- Mike TreselerArticle: 39571
Leon de Boer wrote: > > I have found while using Leonardo spectrum and Baseline for an Altera design > that when I get to 10-15K gates the design leaves bits out of the synthesis. > I have had this sort of behaviour with Actel licenses where they have a gate > limit. I can't seem to get anyone at Altera or exemplar to be able to tell > me absolutely if the free baseline, Leonardo version is gate limited. They are separate releases so it's reasonable to asuume that the bug set is also different. Since the full version costs big bucks, it's also reasonable to assume that something is left out of the Altera-oem version. One thing the Altera version does have is support for both VHDL and Verilog in the same design. This is a high-cost option in the full version of leo. -- Mike TreselerArticle: 39572
hamish@cloud.net.au wrote: > The Virtex-E speed files are still changing. The 4.1i service pack 3 > release has v1.65 of the Virtex-E speed files, and there's some more > slow downs in those (CLB RAM setup time, from memory). A previous > version slowed down some block RAM control inputs. The 3.3 service > pack 8 speed files doubled the block RAM clock-to-out delay. > > Is it possible to use 4.1i speed files when building with 3.3i ? e.g. for an XCV600E I could just copy over the %XILINX%/virtexe/data/v600e.spd from my 4.1i installation to my 3.3i one ?Article: 39573
Weren't you originally going to run your external memory interface at 1/2 the uP clock? If so, then that div2 output is PERFECT to clock your FPGA. But either way, using that clock output from the uP is really a much better solution than trying to design a fully bullet proof asynch interface with its associated delay and complexity. The Spartan DLL can be used to de-skew the 2 clock domains and you should have it made in the shade. Regards Richard Meester <rme@quest-innovations.com> wrote in message news:<3C6A1628.2BBC50FA@quest-innovations.com>... > Hi Jay, > > Why is it not possible, to me these look like two asynchronous systems? > > We have another option. The PLL puts out div2 or div4 or div8 clock i.e. 50Mhz clock, we could feed this clock into a spartanII > dll which puts out a times2/4/8 clock to get it to 100Mhz. Do you think this will work? > > Thanks, > > Richard > > Jay wrote: > > > Wow, thats a messy clock scheme. I think you're either going to have > > to find a way to get the high frequency output of the uP PLL onto your > > PCB or find a way to bypass the PLL altogether on your uP and feed in > > an external clock. The clocking scheme you have described does not > > seem to be realizable by conventional digital techniques. > > > > Richard Meester <rme@quest-innovations.com> wrote in message news:<3C69673E.14128675@quest-innovations.com>... > > > Hi Jay, > > > > > > Jay wrote: > > > > > > > If all your clocks are derived from the same reference and phase > > > > locked then your do not need to worry about metastability other than > > > > the conventional set-up and hold requirements required of your > > > > receiving flip flops common to all standard synchronous designs. Be > > > > aware that the static timing checks done by typical FPGA tools do not > > > > handle multi-clock relationships very well, but a timing back > > > > annotated gate level sim should give you meaningful checks. > > > > > > > > To say it another way, you do not need to do the cascaded flip flip > > > > thing that you would do when you have signals coming in from an > > > > ASYNCHRONOUS clock domain. > > > > > > > > > > The FPGA is not driven by the same clock that drives the CPU, the CPU has an external 10 Mhz and an internal PLL, the FPGA > > > has an external 100Mhz clock, or a 10Mhz clock and uses the spartanII dll's. Having said this it seems that the signals doe > > > come from an asynchronous clock domain right? > > > > > > Since my design is pipelined can i see this pipeline as the cascaded flip flop thing if i check the signals at the end of > > > my pipe? > > > > > > Thanks. > > > > > > Richard > > > > > > > > > > > Regards > > > > > > > > Richard Meester <rme@quest-innovations.com> wrote in message news:<3C68C144.A80A47AE@quest-innovations.com>... > > > > > Hi Jay, > > > > > > > > > > Yes, we have an external CPU and external memory. We develop the FPGA to be a DMA controller and some more activity. > > > > > We have internal registers inside the FPGA which need to be addressed as a memory device. After this the FPGA can > > > > > become bus master. > > > > > > > > > > What i have done now is that i clock the FPGA at 100Mhz, scan the lines and check for the appropriate signals and go > > > > > from there. I have 4 clock cycles at 100Mhz at the moment, but in future will advance to 2 clock cycles to respond. > > > > > Once the FPGA becomes a bus-master i add a pipeline stage which will allow 1 clock cycle addresses and delayed data > > > > > lines when it comes to a read. Also bus turnaround will have a 4 cycle latency. I will transfer chunks of 16/32 words > > > > > so the benefit of the pipeline is definately there. Now my problem is do i need to synchronize and concern about > > > > > metastability on the incomming lines when the FPGA is a memory device for the external processor? > > > > > > > > > > Thanks, > > > > > > > > > > Richard > > > > > > > > > > Jay wrote: > > > > > > > > > > > I think I misunderstood your configuration. Do you have a uP chip > > > > > > that you've purchased talking to your FPGA as a memory device? > > > > > > > > > > > > Richard Meester <rme@quest-innovations.com> wrote in message news:<3C64E594.9060200@quest-innovations.com>... > > > > > > > Hi Jay, > > > > > > > Thanks for the response, > > > > > > > > > > > > > > Jay wrote: > > > > > > > > > > > > > > > I'm going to make some assumptions because I'm not sure if I > > > > > > > > understand your description, correct me if I'm wrong. > > > > > > > > > > > > > > > > Like you suggested, go ahead and run your internal processor at twice > > > > > > > > the external interface. Enable the data capture and data launch flops > > > > > > > > on every other clock. Clock every flip/flop in your design on the > > > > > > > > higher 2X clock. > > > > > > > > > > > > > > > > > > > > > What do you meen by every other clock, clock the lines, and than wait > > > > > > > one clock, and then clock again for the next complete cycle? > > > > > > > > > > > > > > Don't i have a metastability problem with the asynchronous read/write/cs > > > > > > > lines > > > > > > > > > > > > > > the problem is that the signal below is i.e. the r/w signal. it is > > > > > > > asynchronous. if i sample this at twice the frequency i will at > > > > > > > somepoint get the correct valie that i need to trigger on. > > > > > > > > > > > > > > ---\________/------ > > > > > > > > > > > > > > ^ ^ samples at one of these points at 100 Mhz. > > > > > > > ^ DATA must be stable at this point > > > > > > > > > > > > > > However i need to have the data stable before the rising edge of this > > > > > > > signal, which is one clock cycle wide @ 100 Mhz. so i have one clock > > > > > > > cycle to put the data on the bus. > > > > > > > I see how to design this, but i am worried about metastability on the > > > > > > > asynchronous lines. If i need to take care of this i need to add 2 flops > > > > > > > behind it, and after that start making the data available. Overall this > > > > > > > will take me at least 3 clock cycles. > > > > > > > > > > > > > > > > > > > > > Richard > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Don't try to have a 66MHz mem interface and 100MHz internal clock. > > > > > > > > Maintain that 2/1 ratio. Run the memory at 50 and the processor at > > > > > > > > 100 or run the memory at 66, and run the processor at 133MHz. Your > > > > > > > > life will be much easier. > > > > > > > > > > > > > > > > Hope this help, > > > > > > > > Regards > > > > > > > > Richard Meester <rme@quest-innovations.com> wrote in message news:<3C63F9C2.6CBF3BE7@quest-innovations.com>... > > > > > > > > > > > > > > > >>Hi All, > > > > > > > >> > > > > > > > >>I have some problems finding a good design practice for a bus-interface. > > > > > > > >> > > > > > > > >>We have a processor running internally at 100Mhz, and externally at > > > > > > > >>50Mhz (2 internal bus cycles used for 1 complete external bus cycle). > > > > > > > >>Now the addresses are set, the cs lines are set, the re_n and we_n > > > > > > > >>signals are set and the data is set or read. I know all the timing > > > > > > > >>variables on these lines. > > > > > > > >> > > > > > > > >>Now i need to design a bus interface, but i want the internal clock to > > > > > > > >>run at least at 66 Mhz because i need to access ram at this speed and > > > > > > > >>want to keep the internal clock speeds at the same speed. > > > > > > > >> > > > > > > > >>Now how can i best trigger my internal signals, the we_n line goes > > > > > > > >>active low after 8 nsecs of valid data, should i use this signal and > > > > > > > >>feed it into a fflop to trigger on, or should i let the flop trigger at > > > > > > > >>the internal clock speed and detect that the line has changed state and > > > > > > > >>take action from there, or should i make the desing completely > > > > > > > >>combinatorial? > > > > > > > >> > > > > > > > >>Thanks in advance, > > > > > > > >> > > > > > > > >>Richard > > > > > > > >>Article: 39574
"John_H" <johnhandwork@mail.com> schrieb im Newsbeitrag news:3C698327.2923A1E2@mail.com... > Requirement: two sets of 8 memories, 265x8bits. > > The eight 4096 bit rams can be configured as two sets of four RAMs configured > as 2048x2 bits allowing the memory bank select (3 bits) and the address (8 > bits) to give the 2084 addresses in this configuration. > > No muxing required. Uuups, I forgot that. You are right. -- MfG Falk
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