Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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

Custom Search

Messages from 152200

Article: 152200
Subject: Re: FPGA not getting programmed
From: Ed McGettigan <ed.mcgettigan@xilinx.com>
Date: Tue, 19 Jul 2011 17:19:03 -0700 (PDT)
Links: << >>  << T >>  << A >>
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
Subject: Re: XST 13.1 explodes with generic of enum type with only one
From: Christopher Head <chead@is.invalid>
Date: Tue, 19 Jul 2011 21:01:42 -0700
Links: << >>  << T >>  << A >>
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: 152202
Subject: Re: FPGA not getting programmed
From: vasu <vasu.devunuri@gmail.com>
Date: Wed, 20 Jul 2011 00:34:46 -0700 (PDT)
Links: << >>  << T >>  << A >>
On 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
Subject: Re: FPGA not getting programmed
From: "Morten Leikvoll" <mleikvol@yahoo.nospam>
Date: Wed, 20 Jul 2011 12:46:21 +0200
Links: << >>  << T >>  << A >>
"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
Subject: Re: Issues with Soft-Cores
From: Gabor <gabor@szakacs.invalid>
Date: Wed, 20 Jul 2011 12:00:04 -0400
Links: << >>  << T >>  << A >>
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,
Gabor

Article: 152205
Subject: Speed attained by virtex 6
From: "Fpga.Dev69" <fpga.dev69@gmail.com>
Date: Wed, 20 Jul 2011 11:07:31 -0700 (PDT)
Links: << >>  << T >>  << A >>
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

Article: 152206
Subject: Re: Speed attained by virtex 6
From: Gabor <gabor@szakacs.invalid>
Date: Wed, 20 Jul 2011 15:02:56 -0400
Links: << >>  << T >>  << A >>
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.

-- Gabor

Article: 152207
Subject: source synchronous DDR bus with non-continuous clock
From: fpgaace <mikegulotta@gmail.com>
Date: Wed, 20 Jul 2011 20:32:09 -0700 (PDT)
Links: << >>  << T >>  << A >>
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,
Mike

Article: 152208
Subject: Re: source synchronous DDR bus with non-continuous clock
From: Brian Drummond <brian@shapes.demon.co.uk>
Date: Thu, 21 Jul 2011 09:30:10 +0000 (UTC)
Links: << >>  << T >>  << A >>
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.

- Brian

Article: 152209
Subject: Re: source synchronous DDR bus with non-continuous clock
From: fpgaace <mikegulotta@gmail.com>
Date: Thu, 21 Jul 2011 03:45:51 -0700 (PDT)
Links: << >>  << T >>  << A >>
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
Subject: Re: FPGA not getting programmed
From: Dustin Brothers <starsuplightsdown@gmail.com>
Date: Thu, 21 Jul 2011 06:20:16 -0700 (PDT)
Links: << >>  << T >>  << A >>
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
Subject: Re: source synchronous DDR bus with non-continuous clock
From: Dustin Brothers <starsuplightsdown@gmail.com>
Date: Thu, 21 Jul 2011 06:26:50 -0700 (PDT)
Links: << >>  << T >>  << A >>
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
Subject: Re: Speed attained by virtex 6
From: Kolja Sulimma <ksulimma@googlemail.com>
Date: Thu, 21 Jul 2011 06:56:57 -0700 (PDT)
Links: << >>  << T >>  << A >>
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,

Kolja

Article: 152213
Subject: Re: FPGA not getting programmed
From: Gabor <gabor@szakacs.invalid>
Date: Thu, 21 Jul 2011 11:52:42 -0400
Links: << >>  << T >>  << A >>
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.

-- Gabor

Article: 152214
Subject: Re: source synchronous DDR bus with non-continuous clock
From: Gabor <gabor@szakacs.invalid>
Date: Thu, 21 Jul 2011 12:00:15 -0400
Links: << >>  << T >>  << A >>
fpgaace wrote:
> I'm hoping to get some help/advise on how to design this interface.
> We're targeting Spartan-6.
> 
> Theres a bidirectional, source synchronous, DDR, single-ended bus
> running at only 25Mhz.  The problem Im stuck on has to do with a non-
> continuous clock, only running when theres 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 cores 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 theres 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.

-- Gabor

Article: 152215
Subject: Re: source synchronous DDR bus with non-continuous clock
From: Mawa_fugo <ccon67@netscape.net>
Date: Thu, 21 Jul 2011 12:34:11 -0700 (PDT)
Links: << >>  << T >>  << A >>
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 doable





Article: 152216
Subject: Re: source synchronous DDR bus with non-continuous clock
From: nico@puntnl.niks (Nico Coesel)
Date: Fri, 22 Jul 2011 00:20:40 GMT
Links: << >>  << T >>  << A >>
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
Subject: Re: FSL Problem:Data Return and Use
From: "aibk01" <aibk01@n_o_s_p_a_m.n_o_s_p_a_m.gmail.com>
Date: Fri, 22 Jul 2011 01:22:44 -0500
Links: << >>  << T >>  << A >>
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.com

Article: 152218
Subject: Re: FSL Problem:Data Return and Use
From: Brian Drummond <brian@shapes.demon.co.uk>
Date: Fri, 22 Jul 2011 10:00:04 +0000 (UTC)
Links: << >>  << T >>  << A >>
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.

- Brian

Article: 152219
Subject: Re: source synchronous DDR bus with non-continuous clock
From: fpgaace <mikegulotta@gmail.com>
Date: Fri, 22 Jul 2011 05:21:58 -0700 (PDT)
Links: << >>  << T >>  << A >>
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,
Mike

Article: 152220
Subject: Re: source synchronous DDR bus with non-continuous clock
From: "Morten Leikvoll" <mleikvol@yahoo.nospam>
Date: Fri, 22 Jul 2011 15:37:37 +0200
Links: << >>  << T >>  << A >>
"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
Subject: Post-map simulation: timing violation and delays
From: "sdaau" <sd@n_o_s_p_a_m.n_o_s_p_a_m.imi.aau.dk>
Date: Fri, 22 Jul 2011 10:53:50 -0500
Links: << >>  << T >>  << A >>
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: 152222
Subject: Re: Post-map simulation: timing violation and delays
From: "sdaau" <sd@n_o_s_p_a_m.n_o_s_p_a_m.imi.aau.dk>
Date: Fri, 22 Jul 2011 11:42:16 -0500
Links: << >>  << T >>  << A >>
Hi 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.com

Article: 152223
Subject: Re: Issues with Soft-Cores
From: Julius <juliusbaxter@gmail.com>
Date: Fri, 22 Jul 2011 12:08:33 -0700 (PDT)
Links: << >>  << T >>  << A >>
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,

Julius

Article: 152224
Subject: Re: Post-map simulation: timing violation and delays
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Fri, 22 Jul 2011 19:23:41 +0000 (UTC)
Links: << >>  << T >>  << A >>
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:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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

Custom Search