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
On Jul 19, 12:54=A0am, vasu <vasu.devun...@gmail.com> wrote: > On Jul 19, 3:20=A0am, Ed McGettigan <ed.mcgetti...@xilinx.com> wrote: > > > > > > > On Jul 18, 8:32=A0am, "salimbaba" > > > <a1234573@n_o_s_p_a_m.n_o_s_p_a_m.owlpic.com> wrote: > > > >Which signal is being mapped on to the INIT_B pad? =A0And where did = you > > > >constrain this signal to be LOC'ed to? > > > > >You are using LOC constraints on all of your I/O right? > > > > >Ed McGettigan > > > >-- > > > >Xilinx Inc. > > > > It is an IO which i didnt LOC'ed so INIT_B was mapped on to it.And i = am not > > > using LOC constraints on all the IOs .. =A0 =A0 > > > > --------------------------------------- =A0 =A0 =A0 =A0 > > > Posted throughhttp://www.FPGARelated.com > > > Creating a design to be downloaded into a board without fully LOC > > constraining all of the IO is just asking for trouble and can > > potentially damage the FPGA or another device on the board. > > > You need to fix this ASAP and it will very likely resolve your > > original problem. > > > Ed McGettigan > > -- > > Xilinx Inc. > > Ed's point is very much valid. You should fully Constrain all the IO > signals in your design =A0before you start implementation. I have faced > this problem long back. Every board has specific pins for JTAG > interface, but if you don't constrain your IOBs, it may end up in > using these JTAG specific IO's by your normal logic IO signals. > > -- vasu- Hide quoted text - > > - Show quoted text - Some older FPGA families did not use dedicated JTAG pins, but all modern FPGAs do have dedicated JTAG pins. Ed McGettigan -- Xilinx Inc.Article: 152201
On Thu, 30 Jun 2011 11:09:12 +0000 (UTC)
Brian Drummond <brian@shapes.demon.co.uk> wrote:
> > -use_new_parser yes
>
> AHA!
>
> I had heard that XST13 used a new VHDL front end, and was dreading
> training it to understand code tweaked to suit old XST foibles.
>
> If this is a problem with the old parser, that suggests older
> versions of XST might blow up in the same way. Have you tried XST12
> or earlier?
>
> Also it's good to know that both parsers are available in case of
> trouble.
>
> > Apparently it's the default if you're using newer devices, though I
> > haven't investigated that in detail. I'm using a heritage
> > Spartan-3.
> >
> > Problem solved, job done, happy customer.
>
> And if newer really = better, then kudos to the XST team.
>
> I haven't got around to trying out my carefully cultivated nest of
> vipers on ISE13 yet.
>
> - Brian
I do see one unfortunate change from the old parser to the new, at
least for Spartan 3A synthesis: it no longer tells you as clearly when
it recognizes macros. The old parser used to tell you when it
recognized, say, an 8-bit up counter, under "Synthesizing Unit <Foo>",
along with the name of the signal constituting the counter. The new
synthesizer only reports registers and adders. It then goes on to
"Advanced HDL Synthesis", during which it talks about absorbing
registers into counters, and afterwards tells you how many of each
counter there are, but that seems to be it—it was nice to have the
macro recognition right there in the first step, so one could easily
differentiate between "a register and an adder" vs "a counter"; with
the new parser, one would have to cross-check between the two locations
("HDL Synthesis" and "Advanced HDL Synthesis") to make sure everything
that should have been recognized was (since the Advanced HDL Synthesis
section doesn't reprint the list of plain vanilla registers).
Otherwise, it caught a couple of sloppy practices that had previously
escaped (good!) and also reduced my slice count by a bit (better!)
Chris
Article: 152202On Jul 20, 5:19=A0am, Ed McGettigan <ed.mcgetti...@xilinx.com> wrote: > On Jul 19, 12:54=A0am, vasu <vasu.devun...@gmail.com> wrote: > > > > > > > > > > > On Jul 19, 3:20=A0am, Ed McGettigan <ed.mcgetti...@xilinx.com> wrote: > > > > On Jul 18, 8:32=A0am, "salimbaba" > > > > <a1234573@n_o_s_p_a_m.n_o_s_p_a_m.owlpic.com> wrote: > > > > >Which signal is being mapped on to the INIT_B pad? =A0And where di= d you > > > > >constrain this signal to be LOC'ed to? > > > > > >You are using LOC constraints on all of your I/O right? > > > > > >Ed McGettigan > > > > >-- > > > > >Xilinx Inc. > > > > > It is an IO which i didnt LOC'ed so INIT_B was mapped on to it.And = i am not > > > > using LOC constraints on all the IOs .. =A0 =A0 > > > > > --------------------------------------- =A0 =A0 =A0 =A0 > > > > Posted throughhttp://www.FPGARelated.com > > > > Creating a design to be downloaded into a board without fully LOC > > > constraining all of the IO is just asking for trouble and can > > > potentially damage the FPGA or another device on the board. > > > > You need to fix this ASAP and it will very likely resolve your > > > original problem. > > > > Ed McGettigan > > > -- > > > Xilinx Inc. > > > Ed's point is very much valid. You should fully Constrain all the IO > > signals in your design =A0before you start implementation. I have faced > > this problem long back. Every board has specific pins for JTAG > > interface, but if you don't constrain your IOBs, it may end up in > > using these JTAG specific IO's by your normal logic IO signals. > > > -- vasu- Hide quoted text - > > > - Show quoted text - > > Some older FPGA families did not use dedicated JTAG pins, but all > modern FPGAs do have dedicated JTAG pins. > > Ed McGettigan > -- > Xilinx Inc. I faced this problem in Virtex-6 FPGA based design.Article: 152203
"Ed McGettigan" <ed.mcgettigan@xilinx.com> wrote in message news:1b9eb6a7-70d2-44fa-9710-0c2eb22262db@t8g2000prm.googlegroups.com... >Some older FPGA families did not use dedicated JTAG pins, but all >modern FPGAs do have dedicated JTAG pins. I guess modern FPGA's have just sw dedicated jtag pins.. At least Altera's can be used as IO through megafunctions (like sld_virtual_jtag). I agree that's the way to do it instead of letting them loose as generic io.Article: 152204
Slamy wrote: > Hello. > I'm a little bit tinkering with soft core cpus for fpgas, but I really have > serious issues doing so. Thats why I decided to ask some experts and > register here. > > I tried to find a efficient softcpu that is supported by a c compiler. > As I'm working with a Xilinx Spartan-3, I first tried the Microblaze, which > indeed worked. But it's not the solution I was looking for. The Microblaze > should be usable like the Picoblaze, which can just be integrated in a > verilog module with full access to the cpu bus. So I searched further... > > On OpenCores I've stumbled across the "AVR Core" and the microblaze clones > "aeMB" and "openFire". I've tried to integrate these 3 into my project. > Here are my experiences. > > The OpenFire worked in the behavioural simulation as it should. But in post > route simulation it seems to have timing issues and starts to get an > undefined state after some time. > > The aeMB has even issues with the same program I used for the openfire in > behavioural simulation as some registers became undefined after some time. > > The AVR Core has the same issues as the openfire. > > > The Picoblaze is the only soft core I've managed to get working. > But as the instruction memory is a little bit small and there are no c > compilers available, I only used it once. > > Maybe It's because I've missed something that I should have done. > I'm using the somewhat outdated Spartan-3 Starter Kit of Digilent and even > found a SoC on OpenCores that uses the openfire exactly for this board. > But even with the manual that comes with it, I didn't managed to get it > working. > > Except for this project I'm unable to find other that use these cpus. > > What I want to know is, wether there a some people around here that > actually used one of these or maybe have a better one to recommend. > The OpenRISC is to big as it used ~520% of my FPGA. :-D > > I'm writing all this because I now tried to get these working for 2 weeks > and I really can't take it anymore. > > > > > --------------------------------------- > Posted through http://www.FPGARelated.com Have you looked at the "Simple MicroBlaze Microcontroller," described in XAPP1141? I think this was Xilinx's answer to a beefier PicoBlaze with similar ease of use. Regards, GaborArticle: 152205
Dear sir, I am working on the virtex 6, XC6VLX550T FF1759 speed grade -1 , using finite state machines with high operands, (113 bits), in Galois field inverse theory. The problem I face is that I got such results : Timing Summary: --------------- Speed Grade: -1 Minimum period: 1.430ns (Maximum Frequency: 699.301MHz) Minimum input arrival time before clock: 0.910ns Maximum output required time after clock: 0.789ns Maximum combinational path delay: No path found ========================================================================= Process "Synthesize - XST" completed successfully When i sent my paper to one of the journals, one of the reviewers said that it is not possible that the virtex 6 goes beyond the 600Mhz. He said try the place and route, but even though, I am getting the same frequency... Is is true that this frequency is a fake one or perhaps an error from the synthetize tool. Best RegardsArticle: 152206
Fpga.Dev69 wrote: > Dear sir, > I am working on the virtex 6, XC6VLX550T FF1759 speed grade -1 , using > finite state machines with high operands, (113 bits), in Galois field > inverse theory. > The problem I face is that I got such results : > Timing Summary: > --------------- > Speed Grade: -1 > Minimum period: 1.430ns (Maximum Frequency: 699.301MHz) > Minimum input arrival time before clock: 0.910ns > Maximum output required time after clock: 0.789ns > Maximum combinational path delay: No path found > ========================================================================= > > Process "Synthesize - XST" completed successfully > > When i sent my paper to one of the journals, one of the reviewers said > that it is not possible that the virtex 6 goes beyond the 600Mhz. He > said try the place and route, but even though, I am getting the same > frequency... > > Is is true that this frequency is a fake one or perhaps an error from > the synthetize tool. > > Best Regards These numbers (from the synthesis report) are estimates. Your only true timing numbers come after place and route. You'll find them in the post place & route static timing report. To get a meaningful timing report, you should add timing constraints to the design so that the tools have a target to try to achieve. With no constraints, the tools will make some attempt at optimizing the speed, but perhaps not give you the best possible results. -- GaborArticle: 152207
I'm hoping to get some help/advise on how to design this interface. We're targeting Spartan-6. There=92s a bidirectional, source synchronous, DDR, single-ended bus running at only 25Mhz. The problem I=92m stuck on has to do with a non- continuous clock, only running when there=92s data. For the receive side I was thinking the clock would go through a BUFIO2 and clock the data into an IDDR2. Simple enough. Then, to move that data from the IDDR2 into the core=92s clock domain I was planning to use a shallow FIFO. The problem is with the last word and clock edge (after a burst). The last clock edge only gets the data into the IDDR2 register but there=92s not another edge to complete the transfer from the IDDR2 to the FIFO. Thanks in advance. Regards, MikeArticle: 152208
On Wed, 20 Jul 2011 20:32:09 -0700, fpgaace wrote: > I'm hoping to get some help/advise on how to design this interface. > We're targeting Spartan-6. > > There’s a bidirectional, source synchronous, DDR, single-ended bus > running at only 25Mhz. The problem I’m stuck on has to do with a non- > continuous clock, only running when there’s data. > The last > clock edge only gets the data into the IDDR2 register but there’s not > another edge to complete the transfer from the IDDR2 to the FIFO. At that speed you can use a faster internal clock at 100MHz or so, detect edges on the incoming clock, and use that to control a state machine handling all your internal timing requirements. - BrianArticle: 152209
On Jul 21, 4:30=A0am, Brian Drummond <br...@shapes.demon.co.uk> wrote: > On Wed, 20 Jul 2011 20:32:09 -0700, fpgaace wrote: > > I'm hoping to get some help/advise on how to design this interface. > > We're targeting Spartan-6. > > > There=92s a bidirectional, source synchronous, DDR, single-ended bus > > running at only 25Mhz. =A0The problem I=92m stuck on has to do with a n= on- > > continuous clock, only running when there=92s data. =A0 > > The last > > clock edge only gets the data into the IDDR2 register but there=92s not > > another edge to complete the transfer from the IDDR2 to the FIFO. > > At that speed you can use a faster internal clock at 100MHz or so, detect > edges on the incoming clock, and use that to control a state machine > handling all your internal timing requirements. > > - Brian Thanks for the quick reply Brian. That's basically what we have now but its become a challenge in Spartan-6 with all the clocking limitations.Article: 152210
I am wondering if have two FPGAs being programmed from the same EEPROM is even a valid JTAG structure? Someone please correct if I am incorrect and has designed a working system this way before. I would almost lean towards having the JTAG chain only be EEPROM -> FPGA1 Then have FPGA1 read the bit stream out of EEPROM and program FPGA2. Therefore you don't have bus contention between the two FPGAs. FPGA2 is then like a ghost FPGA on the JTAG chain. Does this seem logical? I have just never heard of one EEPROM being dedicated to two FPGAs before with identical bit files.Article: 152211
That's good to know there are clock limitations in the Spartan6. Would you = explain? Is it global routing or buffers for the clock nets on the S6? I find it strange that the DDR interface only has a clock when data is movi= ng.=20 From what I can remember, doesn't the source/master on a "typical" DDR syst= em need to drive a clock for a while prior to the data transfer to allow sy= ncing of clocks due to the windowing nature of data on both edges? Meaning = registering on the receiving node needs to be very tightly synced to the so= urce clock. Maybe this doesn't apply in the source sync model you are using= ? Please correct if I am mistaken.Article: 152212
On 20 Jul., 20:07, "Fpga.Dev69" <fpga.de...@gmail.com> wrote: > Dear sir, > I am working on the virtex 6, XC6VLX550T FF1759 speed grade -1 , using > finite state machines with high operands, (113 bits), in Galois field > inverse theory. > The problem I face is that I got such results : > Timing Summary: > --------------- > Speed Grade: -1 > =A0 =A0Minimum period: 1.430ns (Maximum Frequency: 699.301MHz) > =A0 =A0Minimum input arrival time before clock: 0.910ns > =A0 =A0Maximum output required time after clock: 0.789ns > =A0 =A0Maximum combinational path delay: No path found > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > Process "Synthesize - XST" completed successfully > > When i sent my paper to one of the journals, one of the reviewers said > that it is not possible that the virtex 6 goes beyond the 600Mhz. He > said try the place and route, but even though, I am getting the same > frequency... > > Is is true that this frequency is a fake one or perhaps an error from > the synthetize tool. > > Best Regards It is definitely possible to go beyond 600MHz in a virtex-6. (People where going to 250MHz in XC3195 14 years ago: http://portal.acm.org/citation.cfm?id=3D278544 PDF available via google) However, for a state machine involving 113 bit operands described in a high leve approach I seriously doubt your values.. Follow the advice of the other poster: Use post place and rout timing and provide timing constraints for your clock signals to get a better timing report. Regards, KoljaArticle: 152213
Dustin Brothers wrote: > I am wondering if have two FPGAs being programmed from the same EEPROM is even a valid JTAG structure? Someone please correct if I am incorrect and has designed a working system this way before. I would almost lean towards having the JTAG chain only be > > EEPROM -> FPGA1 > > Then have FPGA1 read the bit stream out of EEPROM and program FPGA2. Therefore you don't have bus contention between the two FPGAs. FPGA2 is then like a ghost FPGA on the JTAG chain. > > Does this seem logical? I have just never heard of one EEPROM being dedicated to two FPGAs before with identical bit files. Actually it is quite common to use a single PROM or flash to program multiple FPGA's. This connection scheme is shown in the Spartan 3 Generation Configuration User Guide. From the other posts in the thread, it seems more likely to be a problem with bit file generation rather than the board-level connections. -- GaborArticle: 152214
fpgaace wrote: > I'm hoping to get some help/advise on how to design this interface. > We're targeting Spartan-6. > > There’s a bidirectional, source synchronous, DDR, single-ended bus > running at only 25Mhz. The problem I’m stuck on has to do with a non- > continuous clock, only running when there’s data. For the receive > side I was thinking the clock would go through a BUFIO2 and clock the > data into an IDDR2. Simple enough. Then, to move that data from the > IDDR2 into the core’s clock domain I was planning to use a shallow > FIFO. The problem is with the last word and clock edge (after a > burst). The last clock edge only gets the data into the IDDR2 > register but there’s not another edge to complete the transfer from > the IDDR2 to the FIFO. > > Thanks in advance. > > Regards, > Mike If you know you have a minimum time that the clock goes inactive, and can detect this condition, you could just bypass the FIFO when the clock is inactive and the FIFO empties. Then you just need a bit more logic to prevent the last word of the previous burst (the one that bypassed the FIFO) from being pushed into the FIFO at the start of the next burst, or alternately ignoring the first word from the FIFO after a new burst starts. -- GaborArticle: 152215
On Jul 21, 5:45=A0am, fpgaace <mikegulo...@gmail.com> wrote: > On Jul 21, 4:30=A0am, Brian Drummond <br...@shapes.demon.co.uk> wrote: > > > > > On Wed, 20 Jul 2011 20:32:09 -0700, fpgaace wrote: > > > I'm hoping to get some help/advise on how to design this interface. > > > We're targeting Spartan-6. > > > > There=92s a bidirectional, source synchronous, DDR, single-ended bus > > > running at only 25Mhz. =A0The problem I=92m stuck on has to do with a= non- > > > continuous clock, only running when there=92s data. =A0 > > > The last > > > clock edge only gets the data into the IDDR2 register but there=92s n= ot > > > another edge to complete the transfer from the IDDR2 to the FIFO. > > > At that speed you can use a faster internal clock at 100MHz or so, dete= ct > > edges on the incoming clock, and use that to control a state machine > > handling all your internal timing requirements. > > > - Brian > > Thanks for the quick reply Brian. =A0That's basically what we have now > but its become a challenge in Spartan-6 with all the clocking > limitations. That's perhaps best approach. Second though, you may try to give the clock 1 or 2 more cycles just to move the data to the FIFO ? I think it's doableArticle: 152216
fpgaace <mikegulotta@gmail.com> wrote: >I'm hoping to get some help/advise on how to design this interface. >We're targeting Spartan-6. > >There=92s a bidirectional, source synchronous, DDR, single-ended bus >running at only 25Mhz. The problem I=92m stuck on has to do with a non- >continuous clock, only running when there=92s data. For the receive >side I was thinking the clock would go through a BUFIO2 and clock the >data into an IDDR2. Simple enough. Then, to move that data from the >IDDR2 into the core=92s clock domain I was planning to use a shallow >FIFO. The problem is with the last word and clock edge (after a >burst). The last clock edge only gets the data into the IDDR2 >register but there=92s not another edge to complete the transfer from >the IDDR2 to the FIFO. Its simple: don't use a FIFO and make sure the incoming DDR clock has a known relationship to the FPGA clock. At 25MHz timing should be really easy. If the transfer is somehow initiated by the FPGA you might be able to tell when to expect the data so you won't need to look at the 25MHz clock. -- Failure does not prove something is impossible, failure simply indicates you are not using the right tools... nico@nctdevpuntnl (punt=.) --------------------------------------------------------------Article: 152217
The build is successful. I can download the Bit file and run it. I can see the data being sent via FSL bus on the hyperterminal by printing the sent values. Now after the values are sent there is no return of data. What shud i do now? --------------------------------------- Posted through http://www.FPGARelated.comArticle: 152218
On Fri, 22 Jul 2011 01:22:44 -0500, aibk01 wrote: > The build is successful. I can download the Bit file and run it. I can > see the data being sent via FSL bus on the hyperterminal by printing the > sent values. > > Now after the values are sent there is no return of data. What shud i do > now? Simulate. - BrianArticle: 152219
On Jul 20, 10:32=A0pm, fpgaace <mikegulo...@gmail.com> wrote: > I'm hoping to get some help/advise on how to design this interface. > We're targeting Spartan-6. > > There=92s a bidirectional, source synchronous, DDR, single-ended bus > running at only 25Mhz. =A0The problem I=92m stuck on has to do with a non= - > continuous clock, only running when there=92s data. =A0For the receive > side I was thinking the clock would go through a BUFIO2 and clock the > data into an IDDR2. =A0Simple enough. =A0Then, to move that data from the > IDDR2 into the core=92s clock domain I was planning to use a shallow > FIFO. =A0The problem is with the last word and clock edge (after a > burst). =A0 The last clock edge only gets the data into the IDDR2 > register but there=92s not another edge to complete the transfer from > the IDDR2 to the FIFO. > > Thanks in advance. > > Regards, > Mike Thanks to all the input. Here's answers to some of the questions, and the final solution... Though its only 25Mhz (50Mbps), the data valid window is approx +/-4ns. Still plenty of margin. The clocks are all derived from an on-board osc so there's really no way to gaurantee a phase relationship of the derived clocks from two different devices, therefore a FIFO is needed to decouple timing (ie., cross clock domains). The driving device is an ASSP so we can't make it generate extra clocks. The solution is to by-pass all IO clocking elements (ie., BUFIO2, ISERDES, etc), and clock data directly into a pair of FIFOs using two BUFGs, one for rising and one for falling edge data. Regards, MikeArticle: 152220
"fpgaace" <mikegulotta@gmail.com> wrote in message news:65471e92-9834-48df-a40e-01b925571c8b@a12g2000vbf.googlegroups.com... >Though its only 25Mhz (50Mbps), the data valid window is approx >+/-4ns. Still plenty of margin. Sounds like you have a fpga that could do (async) clk edge detection at a much higher clock and just use the resampled data at the detected edge?Article: 152221
Hi all,
I am trying to implement a custom counter (with clock and enable inputs);
synthesis and behavioral & post-translate simulation pass just fine (using
ISE WebPack 13.2). On post-map simulation, I get this:
at 271179 ps(5), Instance /my_counter_test/UUT/c_0/ : Warning: /X_FF SETUP
High VIOLATION ON CE WITH RESPECT TO CLK;
Expected := 0.428 ns; Observed := 0.144 ns; At : 271.179 ns
.. as well as X values in my output. I am already aware that I can avoid
the X's by doing `INST "c_0" ASYNC_REG = TRUE;` in the constraints .ucf
file; but that simply gets rid of the X's (in which case I do get correct
values) - however, I'd like to tackle the timing violation.
I was looking for a while into this, and I interpret it like so: the
variable c that I have in my counter code, has been converted by synthesis
process into (at least) one flipflop for each 'bit', c_0 being the FF
corresponding to bit 0 (of variable c). After some searching, I found that
this FF has its own clk and CE inputs - the relationship between the these
signals, and the 'master' clock and enable is shown in the below screenshot
from isim:
http://sdaaubckp.sf.net/post/img/cntr_timing_violation.png
So, I can see that:
* wclk and wenbl are the 'master' signals, and they are synchronous (they
both rise at exactly the same time)
* The delay between wclk(wenbl) and c_0.ce is some 1.035 ns
* The delay between wclk(wenbl) and c_0.clk is some 1.179 ns
* (Thus, the delay between is c_0.ce and c_0.clk is 0.144 ns)
.. and so, I gather, the violation tells us that c_0.ce must be high for
at least 0.428 ns before c_0.clk goes high (i.e. the setup time); however
that state lasted for only 0.144 ns in the simulation, so the simulator
complains.
Now, the most obvious thing would be to insert a delay of at least
0.428-0.144= 0.284 ns between c_0.clk and c_0.ce (or between c_0.clk and
wclk), and I guess then the timing violation would be gone, is that
correct?
However, the problem is that I would not want to move the first clk after
enable in the next period using the state machine - and I have no idea how
to otherwise implement such a delay of ~ 0.3 ns.
I was thinking that timing constraints in the .ucf file would help, and I
was experimenting with some `OFFSET = IN 8 ns VALID 6 ns BEFORE "clk"
RISING;` - and while this helps with Timing Analysis report errors, there
is no change in the simulator. Then again, here I want to *increase* the
(minimum) delay - and as far as I can tell, timing constraints in the .ucf
file serve to limit ("decrease") the (maximum) delay. If that is so, then
ucf file constraints cannot help much with introducing delay, I guess...
So I was wandering - what would be the appropriate method to handle these
timing violations? And have I understood the above situation correctly?
Thanks in advance for any answers,
Cheers!
---------------------------------------
Posted through http://www.FPGARelated.com
Article: 152222Hi again, >* wclk and wenbl are the 'master' signals, and they are synchronous (they >both rise at exactly the same time) >* The delay between wclk(wenbl) and c_0.ce is some 1.035 ns >* The delay between wclk(wenbl) and c_0.clk is some 1.179 ns >* (Thus, the delay between is c_0.ce and c_0.clk is 0.144 ns) > > .... > >Now, the most obvious thing would be to insert a delay of at least >0.428-0.144= 0.284 ns between c_0.clk and c_0.ce ... > >However, the problem is that I would not want to move the first clk after >enable in the next period using the state machine - and I have no idea how >to otherwise implement such a delay of ~ 0.3 ns. > Well, I remembered the old "two inverters in cascade = delay"; so I decided to try that: ... -- simulate delay for enable with two inverters ATTRIBUTE keep : STRING; SIGNAL wi1_enbl, wi2_enbl: STD_LOGIC := 'Z'; ATTRIBUTE keep of wi1_enbl, wi2_enbl: SIGNAL IS "true" ; begin wi1_enbl <= not(enbl); wi2_enbl <= not(wi1_enbl); ... .. and got the stats: wclk to .clk: 1.179 ns; wclk to .ce: 2.158 ns; .clk to .ce: 0.979 ns! So definitely more than the 0.428 ns required (note the delay per inverter gate would be some 0.979-0.144 = 0.4175 ns ; on its own it probably wouldn't be enough - but with the 0.144 built-in from before, if it still exists as a wire delay with these changes, it would have done it). And, needless to say, no more X's in the output, nor violation complaints by ISIM (at least to those related to enbl signal)... Well, that is at least something, I guess - but is there a more appropriate way to solve something like this? Thanks, Cheers! --------------------------------------- Posted through http://www.FPGARelated.comArticle: 152223
On Jul 17, 6:57=A0pm, "Slamy" <andre.zeps@n_o_s_p_a_m.googlemail.com> wrote: > Hello. > I'm a little bit tinkering with soft core cpus for fpgas, but I really ha= ve > serious issues doing so. Thats why I decided to ask some experts and > register here. > > I tried to find a efficient softcpu that is supported by a c compiler. > As I'm working with a Xilinx Spartan-3, I first tried the Microblaze, whi= ch > indeed worked. But it's not the solution I was looking for. The Microblaz= e > should be usable like the Picoblaze, which can just be integrated in a > verilog module with full access to the cpu bus. So I searched further... > > On OpenCores I've stumbled across the "AVR Core" and the microblaze clone= s > "aeMB" and "openFire". I've tried to integrate these 3 into my project. > Here are my experiences. > > The OpenFire worked in the behavioural simulation as it should. But in po= st > route simulation it seems to have timing issues and starts to get an > undefined state after some time. > > The aeMB has even issues with the same program I used for the openfire in > behavioural simulation as some registers became undefined after some time= . > > The AVR Core has the same issues as the openfire. > > The Picoblaze is the only soft core I've managed to get working. > But as the instruction memory is a little bit small and there are no c > compilers available, I only used it once. > > Maybe It's because I've missed something that I should have done. > I'm using the somewhat outdated Spartan-3 Starter Kit of Digilent and eve= n > found a SoC on OpenCores that uses the openfire exactly for this board. > But even with the manual that comes with it, I didn't managed to get it > working. > > Except for this project I'm unable to find other that use these cpus. > > What I want to know is, wether there a some people around here that > actually used one of these or maybe have a better one to recommend. > The OpenRISC is to big as it used ~520% of my FPGA. :-D > > I'm writing all this because I now tried to get these working for 2 weeks > and I really can't take it anymore. > > --------------------------------------- =A0 =A0 =A0 =A0 > Posted throughhttp://www.FPGARelated.com Hi, Regarding OpenRISC resource usage, it's very configurable, and I believe it'll fit on most FPGAs that come on those types of development boards, even with room to spare if you turn off things like FPU, MAC, and turn down the cache sizes. I'd be willing to help you get it up and running on your board. I help maintain a project called ORPSoC - part of the OpenRISC project - you can usually find me in #opencores on irc.freenode.net I understand it can be a bit difficult to get this stuff up and running, and I'm interested in making it easy for new comers to get going and would like to find out exactly what parts didn't work for you when you tried things out. Of late, the OpenRISC's GNU toolchain port has been significantly upgraded, so too various libraries, debugging utilities and its Linux kernel port (so much so it'll be in mainline before long.) I think it's not a bad platform and am interested in working to make it easier to use. Your feedback would be very useful. So please drop by the mailing lists on openrisc.net or the IRC. Cheers, JuliusArticle: 152224
sdaau <sd@n_o_s_p_a_m.n_o_s_p_a_m.imi.aau.dk> wrote: (snip) >>Now, the most obvious thing would be to insert a delay of at least >>0.428-0.144= 0.284 ns between c_0.clk and c_0.ce ... (snip) > Well, I remembered the old "two inverters in cascade = delay"; > so I decided to try that: I presume you forced it to keep the inverters, otherwise they will usually optimize away. You might try with only one forced, in which case it will optmize the other by inverting the signal somewhere else. Or with a forced non-inverting gate. (snip) > Well, that is at least something, I guess - but is there a > more appropriate way to solve something like this? -- glen
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