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 158125

Article: 158125
Subject: Re: fifo or sdram bug?
From: "kaz" <37480@FPGARelated>
Date: Thu, 13 Aug 2015 08:00:08 -0500
Links: << >>  << T >>  << A >>
I am still trying to figure out this issue of odd/even offset. My
suspicion has fallen on a dual clock fifo (32 bit wide) because when at
some stage its depth was 8 then odd/even offset was 8 samples. Now its
depth is 16 and odd/even offset is 16.

The next question is why would a fifo behave like that even if clocks
change phase or fifo gets empty/full. 

The fifo is protected against empty/full preventing read/write. The clocks
are asynchronous. It is a straight forward dc fifo with several other like
it in the design but only this one shows the problem occasionally.

I am planning to use dual port ram instead but wanted to know what has
gone wrong.

Kaz
---------------------------------------
Posted through http://www.FPGARelated.com

Article: 158126
Subject: Re: Finally! A Completely Open Complete FPGA Toolchain
From: hamilton <hamilton@nothere.com>
Date: Thu, 13 Aug 2015 08:11:06 -0600
Links: << >>  << T >>  << A >>
On 8/13/2015 6:07 AM, Philipp Klaus Krause wrote:
> The SDCC PIC backends are not up to the standard of the others.

Is the PIC too much of an odd ball to keep up with
or
is there no future in 8-bit PIC ?
or
are 32-bit chips more fun ?

If there is a better place to discuss this, please let me know.


Article: 158127
Subject: Re: Finally! A Completely Open Complete FPGA Toolchain
From: rickman <gnuarm@gmail.com>
Date: Thu, 13 Aug 2015 10:20:16 -0400
Links: << >>  << T >>  << A >>
On 8/13/2015 10:11 AM, hamilton wrote:
> On 8/13/2015 6:07 AM, Philipp Klaus Krause wrote:
>> The SDCC PIC backends are not up to the standard of the others.
>
> Is the PIC too much of an odd ball to keep up with
> or
> is there no future in 8-bit PIC ?
> or
> are 32-bit chips more fun ?
>
> If there is a better place to discuss this, please let me know.

I don't know tons about the 32 bit chips which are mostly ARMs.  But the 
initialization is more complex.  It is a good idea to let the tools 
handle that for you.  All of the 8 bit chips I've used were very simple 
to get off the ground.

-- 

Rick

Article: 158128
Subject: Re: Finally! A Completely Open Complete FPGA Toolchain
From: Philipp Klaus Krause <pkk@spth.de>
Date: Thu, 13 Aug 2015 18:07:17 +0200
Links: << >>  << T >>  << A >>
On 13.08.2015 16:11, hamilton wrote:
> On 8/13/2015 6:07 AM, Philipp Klaus Krause wrote:
>> The SDCC PIC backends are not up to the standard of the others.
> 
> Is the PIC too much of an odd ball to keep up with
> or
> is there no future in 8-bit PIC ?
> or
> are 32-bit chips more fun ?

I don't consider 32-bit chips more fun. I like CISC 8-bitters, but I
prefer those that seem better suited for C. Again SDCC has few
developers, and at least recently, the most active ones don't seem that
interested in the pics.

Also, the situation is quite different between the pic14 and pic16
backends. The pic16 backend is not that bad. If someone puts a few weeks
of work into it, it could probably make it up to the standard of the
other ports in terms of correctness; it already passes large parts of
the regular regression test suite. The pic14 would require much more work.

> 
> If there is a better place to discuss this, please let me know.
> 

The sdcc-user and sdcc-devel seem a better place than comp.arch.fpga.

Philipp


Article: 158129
Subject: Re: fifo or sdram bug?
From: KJ <kkjennings@sbcglobal.net>
Date: Thu, 13 Aug 2015 11:26:39 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Thursday, August 13, 2015 at 9:00:13 AM UTC-4, kaz wrote:
>=20
> The next question is why would a fifo behave like that even if clocks
> change phase or fifo gets empty/full.=20
>=20

If your suspicion is correct, then it is because there is a bug in the dual=
 clock design.  I know that sounds trite, but you can't discount the obviou=
s.

> The fifo is protected against empty/full preventing read/write. The clock=
s
> are asynchronous. It is a straight forward dc fifo with several other lik=
e
> it in the design but only this one shows the problem occasionally.
>=20
Home grown fifo design?

> I am planning to use dual port ram instead but wanted to know what has
> gone wrong.
>=20
Even if the fifo is not home grown, I would suggest switching to another du=
al clock fifo design first for the following reasons:
- It's going to be quicker to check this out since in some sense all you ha=
ve to change is the entity that is being instantiated and possibly renaming=
 parameters and ports
- You get another tidbit of information.  If the design still fails in the =
same way, then it 'could' be that the fifo is OK after all.  If the design =
works, then it 'could' be that you're right about there being a problem in =
the fifo.

If you go down the 'use dual port ram instead' path instead, this is simply=
 re-inventing the dual clock fifo.  Dual clock fifo designs are already bas=
ed on dual port ram anyway.  Going down that road is probably not the best =
way to go about getting to a solution.

If the problem really is in the fifo, then it would be better to mentally t=
race it back in order to figure out what you could then instrument.  In thi=
s particular case what I mean is that from what you describe, it looks like=
 a bit in the read address is perhaps into the wrong state.  So accept that=
 as a given and work out what are the implications of that condition?  One =
implication if the address pointer is suddenly wrong might be an unusual ch=
ange in the number of entries in the fifo (like increasing after a read, or=
 decreasing after a write or just changing by a 'large' amount over a short=
 period).  Now add some logic to monitor that condition and bring the resul=
ts of that monitor out to a pin that you can trigger on.  For example, mayb=
e the number of words in the fifo should never change by more than 4 betwee=
n any two read side clock cycles.  So add some code that will detect that c=
ondition.  Repeat for other conditions that you can come up with.

Kevin Jennings

Article: 158130
Subject: Re: fifo or sdram bug?
From: "kaz" <37480@FPGARelated>
Date: Thu, 13 Aug 2015 14:00:03 -0500
Links: << >>  << T >>  << A >>
The fifo is not home grown. It is altera fifo core. We never discard well
tried cores for home made work.

DC fifo is built by Altera around dual ram but if (as in my case) the
clock rates are predictable then one can control wr/rd pointers each in
their clock domain without having to cross clock domains thus reducing
risk and resource. That is my point and is well known design
recommendation.

The fifo in question is just 32 bit wide dc fifo from altera core with
internal pipe set to 3, rd/wr protected, connected to clk 368.64 at write
side enabled 2/3 and connected to 245.76 on the read side always enabled.
Initially the read
enable is delayed to wait for few words (even though it is protected).

Timing is clean. I imagine the write pointer is working but the read
pointer is toggling between 0 and 15 with two clock delays leading to
samples 0,17,2,19 ...etc. Just a guess.

I have put a ram to capture few data from this fifo in the field when
problem occurs and I am awaiting results.
---------------------------------------
Posted through http://www.FPGARelated.com

Article: 158131
Subject: Re: fifo or sdram bug?
From: thomas.entner99@gmail.com
Date: Thu, 13 Aug 2015 14:05:44 -0700 (PDT)
Links: << >>  << T >>  << A >>
Am Donnerstag, 13. August 2015 21:00:07 UTC+2 schrieb kaz:
> The fifo is not home grown. It is altera fifo core. We never discard well
> tried cores for home made work.
>=20
> DC fifo is built by Altera around dual ram but if (as in my case) the
> clock rates are predictable then one can control wr/rd pointers each in
> their clock domain without having to cross clock domains thus reducing
> risk and resource. That is my point and is well known design
> recommendation.
>=20
> The fifo in question is just 32 bit wide dc fifo from altera core with
> internal pipe set to 3, rd/wr protected, connected to clk 368.64 at write
> side enabled 2/3 and connected to 245.76 on the read side always enabled.
> Initially the read
> enable is delayed to wait for few words (even though it is protected).
>=20
> Timing is clean. I imagine the write pointer is working but the read
> pointer is toggling between 0 and 15 with two clock delays leading to
> samples 0,17,2,19 ...etc. Just a guess.
>=20
> I have put a ram to capture few data from this fifo in the field when
> problem occurs and I am awaiting results.
> ---------------------------------------
> Posted through http://www.FPGARelated.com

I have seen random/strange issues with Altera FIFOs in the past more than o=
nce (but still seldom). In that cases I replaced the FIFOs with "home grown=
" ones and the problems were solved. I never tracked that down in detail (m=
aybe it was related to the clear signal in some way...) and I also cannot r=
emember details (one or two clocks, same or different width in/out), I have=
 used so many FIFOs (mostly successfully) over the years...

I would suggest to look at all inputs and outputs of the FIFO with SignalTa=
p and see if it behaves correctly.

P.S.: Oh, I just read your initial post that you cannot reproduce it in the=
 lab...

P.P.S.: I have googled around to find an old post of me regarding this. I f=
ailed. But I found this:
https://www.altera.com/support/support-resources/knowledge-base/solutions/r=
d11182011_10.html
and this:
https://www.altera.com/support/support-resources/knowledge-base/solutions/r=
d02232015_507.html
(Maybe there are more...)

So I would suggest to replace the FIFOs with a home grown approach and look=
 if this solves the issues in field...

Regards,

Thomas

www.entner-electronics.com - Home of EEBlaster


Article: 158132
Subject: Re: fifo or sdram bug?
From: "kaz" <37480@FPGARelated>
Date: Thu, 13 Aug 2015 16:40:36 -0500
Links: << >>  << T >>  << A >>

Thanks Thomas. These two links could explain it well though my quartus is
older version but I assume Altera have bug in reporting their bug as well.
The link says the possibility of failure increases with speed and logic
size. Our speed of 368.64/245.76MHz is certainly fast and the logic we
have is massive.

Altera says unpredictable behaviour in hardware without telling as what
sort of behaviour. I will certainly go for dual port ram without grey
counter or clock crossing. 

---------------------------------------
Posted through http://www.FPGARelated.com

Article: 158133
Subject: Re: Finally! A Completely Open Complete FPGA Toolchain
From: thomas.entner99@gmail.com
Date: Thu, 13 Aug 2015 18:44:01 -0700 (PDT)
Links: << >>  << T >>  << A >>
> Again SDCC has few
> developers, and at least recently, the most active ones don't seem that
> interested in the pics.
>=20
Back to the topic of the open FPGA tool chain, I think there would be many =
"PICs", i.e. topics which are addressed by no / too few developers.

But the whole discussion is quite theoretical as long as A & X do not open =
their bitstream formats. And I do not think that they will do anything that=
 will support an open source solution, as software is the main entry obstac=
le for FPGA startups. If there would be a flexible open-source tool-chain w=
ith large developer and user-base that can be ported to new architectures e=
asily, this would make it much easier for new competition. (Think gcc...)

Also (as mentioned above) I think with the good and free tool chains from t=
he suppliers, their would be not much demand for such a open source tool ch=
ain. There are other points where I would see more motiviation and even the=
re is not happening much:
- Good open source Verilog/VHDL editor (Yes, I have heard of Emacs...) as t=
he integrated editors are average (Altera) or bad (Xilinx). (Currently I am=
 evaluating two commercial VHDL editors...)
- A kind of graphical editor for VHDL and Verilog as the top/higher levels =
of bigger projects are often a pain IMHO (like writing netlists by hand). I=
 would even start such a project myself if I had the time...

But even with such things where I think would be quite some demand, the "cr=
itical mass" of the FPGA community is too low to get projects started and e=
specially keep them running.

Thomas

Article: 158134
Subject: Re: Finally! A Completely Open Complete FPGA Toolchain
From: Richard Damon <Richard@Damon-Family.org>
Date: Thu, 13 Aug 2015 23:17:50 -0400
Links: << >>  << T >>  << A >>
On 8/13/15 9:44 PM, thomas.entner99@gmail.com wrote:
>> Again SDCC has few
>> developers, and at least recently, the most active ones don't seem that
>> interested in the pics.
>>
> Back to the topic of the open FPGA tool chain, I think there would
> bemany "PICs", i.e. topics which are addressed by no / too few developers.
>
> But the whole discussion is quite theoretical as long as A & X do
> not  open their bitstream formats. And I do not think that they will do
> anything that will support an open source solution, as software is the
> main entry obstacle for FPGA startups. If there would be a flexible
> open-source tool-chain with large developer and user-base that can be
> ported to new architectures easily, this would make it much easier for
> new competition. (Think gcc...)
>
> Also (as mentioned above) I think with the good and free tool chains
> from the suppliers, their would be not much demand for such a open
> source tool chain. There are other points where I would see more
> motiviation and even there is not happening much:
> - Good open source Verilog/VHDL editor (Yes, I have heard of
> Emacs...)
> as the integrated editors are average (Altera) or bad (Xilinx).
> (Currently I am evaluating two commercial VHDL editors...)
> - A kind of graphical editor for VHDL and Verilog as the top/higher
levels of bigger projects are often a pain IMHO (like writing netlists
by hand). I would even start such a project myself if I had the time...
>
> But even with such things where I think would be quite some demand,
> the "critical mass" of the FPGA community is too low to get projects
> started and especially keep them running.
>
> Thomas
>

One big factor against an open source tool chain is that while the FPGA 
vendors describe in general terms the routing inside the devices, the 
precise details are not given, and I suspect that these details may be 
considered as part of the "secret sauce" that makes the device work. The 
devices have gotten so big and complicated, that it is impractical to 
use fully populated muxes, and how you chose what gets to what is important.

Processors can also have little details like this, but for processors it 
tends to just affect the execution speed, and a compiler that doesn't 
take them into account can still do a reasonable job. For an FPGA, 
without ALL the details for this you can't even do the routing.

Article: 158135
Subject: Re: fifo or sdram bug?
From: Thomas Stanka <usenet_nospam_valid@stanka-web.de>
Date: Thu, 13 Aug 2015 23:23:36 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hello,

Am Donnerstag, 13. August 2015 23:40:39 UTC+2 schrieb kaz:
> Altera says unpredictable behaviour in hardware without telling as what
> sort of behaviour. I will certainly go for dual port ram without grey
> counter or clock crossing.=20

I have no experience with Altera, but remember long time ago a "bug" for Xi=
linx with RAM, where I heard this was in fact related to weakness in test r=
outines to identify production failures. Microsemi had also ~2 years ago so=
me RAM related issues were I believer long routing of signals addressing RA=
M was not correct annotated which might lead to STA say clean, but real tim=
ing was not clean. =20

I had once a problem with a design, which behaved in rare cases in field st=
range while lab showed long time no problem and it took very long to track =
the error to an bug in external USB software, I know therefore how nasty it=
 is to proove over and over again, that fpga internal timing is fine for ev=
ery clock crossing.

regards Thomas

Article: 158136
Subject: Re: fifo or sdram bug?
From: KJ <kkjennings@sbcglobal.net>
Date: Fri, 14 Aug 2015 05:00:10 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Thursday, August 13, 2015 at 5:40:39 PM UTC-4, kaz wrote:
> Thanks Thomas. These two links could explain it well though my quartus is
> older version but I assume Altera have bug in reporting their bug as well=
.

What version of Quartus are you using?  The one link says it applies only t=
o 11.1 with a fix starting with 11.1 SP1.  The other link does not specify =
a software version number but the report is dated just over one month ago w=
hich suggests that the problem has resurfaced.  Your best bet then would be=
 get on Altera to see what the latest word is on a fix here

> The link says the possibility of failure increases with speed and logic
> size.=20

I see no mention of that

> I will certainly go for dual port ram without grey counter or clock cross=
ing.=20
This doesn't make much sense...but anyway, it appears that there is anecdot=
al evidence of a problem with applying timing constraints that can cause th=
e fifo you are using to fail so you're likely getting to the root cause.

Kevin Jennings

Article: 158137
Subject: Re: fifo or sdram bug?
From: KJ <kkjennings@sbcglobal.net>
Date: Fri, 14 Aug 2015 05:06:26 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Thursday, August 13, 2015 at 5:40:39 PM UTC-4, kaz wrote:
> Thanks Thomas. These two links could explain it well though my quartus is
> older version but I assume Altera have bug in reporting their bug as well.

What version of Quartus are you using?  The one report is specific to only 11.1 with a fix in 11.1 SP1.  The other report is from a bit over a month ago and doesn't link it to a specific version but obviously the problem seems to have resurfaced.

> The link says the possibility of failure increases with speed and logic
> size. 

No it doesn't

> I will certainly go for dual port ram without grey counter or clock crossing. 

This makes no sense...but in any case you now have anecdotal evidence of how incorrect timing constraints can result in a failure of the fifo that you are using so you are likely close to a solution.

Kevin Jennings

Article: 158138
Subject: Re: fifo or sdram bug?
From: "kaz" <37480@FPGARelated>
Date: Fri, 14 Aug 2015 08:10:16 -0500
Links: << >>  << T >>  << A >>
>On Thursday, August 13, 2015 at 5:40:39 PM UTC-4, kaz wrote:
>> Thanks Thomas. These two links could explain it well though my quartus
is
>> older version but I assume Altera have bug in reporting their bug as
>well.
>
>What version of Quartus are you using?  The one report is specific to
only
>11.1 with a fix in 11.1 SP1.  The other report is from a bit over a
month
>ago and doesn't link it to a specific version but obviously the problem
>seems to have resurfaced.
>
>> The link says the possibility of failure increases with speed and
logic
>> size. 
>
>No it doesn't
>
 here is the copy/paste from second link

The probability of a hardware failures increases as the logic utilization
and DCFIFO clock rates increase.

---------------------------------------
Posted through http://www.FPGARelated.com

Article: 158139
Subject: Re: fifo or sdram bug?
From: "kaz" <37480@FPGARelated>
Date: Fri, 14 Aug 2015 08:17:53 -0500
Links: << >>  << T >>  << A >>

>
>> I will certainly go for dual port ram without grey counter or clock
>crossing. 
>
>This makes no sense...
>
>Kevin Jennings

Kevin,

I will be interested to see why it doesn't make sense.
Though wr/rd clocks are asynchronous but write rate = read rate regularly.
I don't need to worry about pointer/flag crossing. fifo is 16 words deep.
I wait till it is half full and start reading non stop each side running
its own address generated in its clock domain. It should have been dual
port ram only in the first place.

---------------------------------------
Posted through http://www.FPGARelated.com

Article: 158140
Subject: Re: fifo or sdram bug?
From: KJ <kkjennings@sbcglobal.net>
Date: Fri, 14 Aug 2015 06:58:55 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Friday, August 14, 2015 at 9:17:56 AM UTC-4, kaz wrote:
>=20
> I will be interested to see why it doesn't make sense.

"...without grey counter or clock crossing" didn't make much sense since yo=
u still have two clocks and there will still be clock domain crossings.  Th=
ose crossings will just occur between domains where there is a specified ph=
ase relationship which does open up alternative solutions over situations w=
here you don't have such a relationship.  It's not worth belaboring here, s=
ounds like you know what you want to implement.

Kevin

Article: 158141
Subject: Re: Finally! A Completely Open Complete FPGA Toolchain
From: rickman <gnuarm@gmail.com>
Date: Fri, 14 Aug 2015 13:29:50 -0400
Links: << >>  << T >>  << A >>
On 8/13/2015 11:17 PM, Richard Damon wrote:
> On 8/13/15 9:44 PM, thomas.entner99@gmail.com wrote:
>>> Again SDCC has few
>>> developers, and at least recently, the most active ones don't seem that
>>> interested in the pics.
>>>
>> Back to the topic of the open FPGA tool chain, I think there would
>> bemany "PICs", i.e. topics which are addressed by no / too few
>> developers.
>>
>> But the whole discussion is quite theoretical as long as A & X do
>> not  open their bitstream formats. And I do not think that they will do
>> anything that will support an open source solution, as software is the
>> main entry obstacle for FPGA startups. If there would be a flexible
>> open-source tool-chain with large developer and user-base that can be
>> ported to new architectures easily, this would make it much easier for
>> new competition. (Think gcc...)
>>
>> Also (as mentioned above) I think with the good and free tool chains
>> from the suppliers, their would be not much demand for such a open
>> source tool chain. There are other points where I would see more
>> motiviation and even there is not happening much:
>> - Good open source Verilog/VHDL editor (Yes, I have heard of
>> Emacs...)
>> as the integrated editors are average (Altera) or bad (Xilinx).
>> (Currently I am evaluating two commercial VHDL editors...)
>> - A kind of graphical editor for VHDL and Verilog as the top/higher
> levels of bigger projects are often a pain IMHO (like writing netlists
> by hand). I would even start such a project myself if I had the time...
>>
>> But even with such things where I think would be quite some demand,
>> the "critical mass" of the FPGA community is too low to get projects
>> started and especially keep them running.
>>
>> Thomas
>>
>
> One big factor against an open source tool chain is that while the FPGA
> vendors describe in general terms the routing inside the devices, the
> precise details are not given, and I suspect that these details may be
> considered as part of the "secret sauce" that makes the device work. The
> devices have gotten so big and complicated, that it is impractical to
> use fully populated muxes, and how you chose what gets to what is
> important.

I'm not sure what details of routing aren't available.  There  may not 
be a document which details it all, but last I saw, there were chip 
level design tools which allow you to see all of the routing and 
interconnects.  The delay info can be extracted from the timing analysis 
tools.  As far as I am aware, there is no "secret sauce".


> Processors can also have little details like this, but for processors it
> tends to just affect the execution speed, and a compiler that doesn't
> take them into account can still do a reasonable job. For an FPGA,
> without ALL the details for this you can't even do the routing.

Timing data in an FPGA may be difficult to extract, but otherwise I 
think all the routing info is readily available.

-- 

Rick

Article: 158142
Subject: Re: fifo or sdram bug?
From: rickman <gnuarm@gmail.com>
Date: Fri, 14 Aug 2015 13:32:01 -0400
Links: << >>  << T >>  << A >>
On 8/14/2015 9:58 AM, KJ wrote:
> On Friday, August 14, 2015 at 9:17:56 AM UTC-4, kaz wrote:
>>
>> I will be interested to see why it doesn't make sense.
>
> "...without grey counter or clock crossing" didn't make much sense since you still have two clocks and there will still be clock domain crossings.  Those crossings will just occur between domains where there is a specified phase relationship which does open up alternative solutions over situations where you don't have such a relationship.  It's not worth belaboring here, sounds like you know what you want to implement.

I'm not clear on how a clock domain crossing can have any timing 
restrictions.  Clock domain crossings can be between async clocks which 
can have any phase relationship on any clock edge, varying with each 
cycle.  So how can you possibly apply timing constraints to that?

-- 

Rick

Article: 158143
Subject: Re: Finally! A Completely Open Complete FPGA Toolchain
From: Richard Damon <Richard@Damon-Family.org>
Date: Fri, 14 Aug 2015 21:32:40 -0400
Links: << >>  << T >>  << A >>
On 8/14/15 1:29 PM, rickman wrote:
> On 8/13/2015 11:17 PM, Richard Damon wrote:
>>
>> One big factor against an open source tool chain is that while the FPGA
>> vendors describe in general terms the routing inside the devices, the
>> precise details are not given, and I suspect that these details may be
>> considered as part of the "secret sauce" that makes the device work. The
>> devices have gotten so big and complicated, that it is impractical to
>> use fully populated muxes, and how you chose what gets to what is
>> important.
>
> I'm not sure what details of routing aren't available.  There  may not
> be a document which details it all, but last I saw, there were chip
> level design tools which allow you to see all of the routing and
> interconnects.  The delay info can be extracted from the timing analysis
> tools.  As far as I am aware, there is no "secret sauce".
>
>
>> Processors can also have little details like this, but for processors it
>> tends to just affect the execution speed, and a compiler that doesn't
>> take them into account can still do a reasonable job. For an FPGA,
>> without ALL the details for this you can't even do the routing.
>
> Timing data in an FPGA may be difficult to extract, but otherwise I
> think all the routing info is readily available.
>

My experience is that you get to see what location a given piece of 
logic, and which channels it travels. You do NOT see which particular 
wire in that channel is being used. In general, each logic cell does not 
have routing to every wire in that channel, and every wire does not have 
access to every cross wire. These details tend to be the secret sauce, 
as when they do it well, you aren't supposed to notice the incomplete 
connections.

I have had to work with the factory on things like this. I had a very 
full FPGA and needed to make a small change. With the change I had some 
over clogged routing, but if I removed all internal constraints the 
fitter couldn't find a fit. Working with someone who did know the 
details, we were able to relax just a few internal constraints and get 
the system to fit the design. He did comment that my design was probably 
the fullest design he had seen in the wild, we had grown to about 95% 
logic utilization.

Article: 158144
Subject: Re: Finally! A Completely Open Complete FPGA Toolchain
From: rickman <gnuarm@gmail.com>
Date: Fri, 14 Aug 2015 22:59:27 -0400
Links: << >>  << T >>  << A >>
On 8/14/2015 9:32 PM, Richard Damon wrote:
> On 8/14/15 1:29 PM, rickman wrote:
>> On 8/13/2015 11:17 PM, Richard Damon wrote:
>>>
>>> One big factor against an open source tool chain is that while the FPGA
>>> vendors describe in general terms the routing inside the devices, the
>>> precise details are not given, and I suspect that these details may be
>>> considered as part of the "secret sauce" that makes the device work. The
>>> devices have gotten so big and complicated, that it is impractical to
>>> use fully populated muxes, and how you chose what gets to what is
>>> important.
>>
>> I'm not sure what details of routing aren't available.  There  may not
>> be a document which details it all, but last I saw, there were chip
>> level design tools which allow you to see all of the routing and
>> interconnects.  The delay info can be extracted from the timing analysis
>> tools.  As far as I am aware, there is no "secret sauce".
>>
>>
>>> Processors can also have little details like this, but for processors it
>>> tends to just affect the execution speed, and a compiler that doesn't
>>> take them into account can still do a reasonable job. For an FPGA,
>>> without ALL the details for this you can't even do the routing.
>>
>> Timing data in an FPGA may be difficult to extract, but otherwise I
>> think all the routing info is readily available.
>>
>
> My experience is that you get to see what location a given piece of
> logic, and which channels it travels. You do NOT see which particular
> wire in that channel is being used. In general, each logic cell does not
> have routing to every wire in that channel, and every wire does not have
> access to every cross wire. These details tend to be the secret sauce,
> as when they do it well, you aren't supposed to notice the incomplete
> connections.

Don't they still have the chip editor?  That *must* show everything of 
importance.


> I have had to work with the factory on things like this. I had a very
> full FPGA and needed to make a small change. With the change I had some
> over clogged routing, but if I removed all internal constraints the
> fitter couldn't find a fit. Working with someone who did know the
> details, we were able to relax just a few internal constraints and get
> the system to fit the design. He did comment that my design was probably
> the fullest design he had seen in the wild, we had grown to about 95%
> logic utilization.

Yeah, that's pretty full.  I start to worry around 80%, but I've never 
actually had one fail to route other than the ones I tried to help by 
doing placement, lol.

-- 

Rick

Article: 158145
Subject: Re: fifo or sdram bug?
From: KJ <kkjennings@sbcglobal.net>
Date: Fri, 14 Aug 2015 21:09:21 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Friday, August 14, 2015 at 1:32:02 PM UTC-4, rickman wrote:
> On 8/14/2015 9:58 AM, KJ wrote:
> > On Friday, August 14, 2015 at 9:17:56 AM UTC-4, kaz wrote:
> >>
> >> I will be interested to see why it doesn't make sense.
> >
> > "...without grey counter or clock crossing" didn't make much sense sinc=
e you still have two clocks and there will still be clock domain crossings.=
  Those crossings will just occur between domains where there is a specifie=
d phase relationship which does open up alternative solutions over situatio=
ns where you don't have such a relationship.  It's not worth belaboring her=
e, sounds like you know what you want to implement.
>=20
> I'm not clear on how a clock domain crossing can have any timing=20
> restrictions.  Clock domain crossings can be between async clocks which=
=20
> can have any phase relationship on any clock edge, varying with each=20
> cycle.  So how can you possibly apply timing constraints to that?
>=20

Kaz's earlier posts indicated that the two clocks in question had a fixed p=
hase relationship so he was going to try to take advantage of that in some =
fashion.  So there are still multiple clock domains, therefore there are cr=
ossings but the two clocks are not truly asynchronous (unless Kaz has been =
holding back on his description of the clocks).

If the clocks truly have a fixed phase relationship, then a failure that wo=
uld occur only one in a bazillion lifetimes if the clocks had been asynchro=
nous could tend to show up much more frequently since the failing timing pa=
ths could be way more likely to be occurring on almost every clock cycle, n=
ot just when the clock phases drifted into just the wrong alignment.

Kevin

Article: 158146
Subject: Re: Finally! A Completely Open Complete FPGA Toolchain
From: Richard Damon <Richard@Damon-Family.org>
Date: Sat, 15 Aug 2015 08:32:26 -0400
Links: << >>  << T >>  << A >>
On 8/14/15 10:59 PM, rickman wrote:
> On 8/14/2015 9:32 PM, Richard Damon wrote:
>>
>> My experience is that you get to see what location a given piece of
>> logic, and which channels it travels. You do NOT see which particular
>> wire in that channel is being used. In general, each logic cell does not
>> have routing to every wire in that channel, and every wire does not have
>> access to every cross wire. These details tend to be the secret sauce,
>> as when they do it well, you aren't supposed to notice the incomplete
>> connections.
>
> Don't they still have the chip editor?  That *must* show everything of
> importance.

The chip editors tend to just show the LOGIC resources, not the details 
of the routing resources. The manufactures tend to do a good job of 
giving the detail of the logic blocks you are working with, as this is 
the part of the design you tend to specify. Routing on the other hand 
tends to not be something you care about, just that the routing 'works'. 
When they have done a good job at designing the routing you don't notice 
it, but there have been cases where the routing turned out not quite 
flexible enough and you notice that you can't fill the device as well 
before hitting routing issues.
>
>
>> I have had to work with the factory on things like this. I had a very
>> full FPGA and needed to make a small change. With the change I had some
>> over clogged routing, but if I removed all internal constraints the
>> fitter couldn't find a fit. Working with someone who did know the
>> details, we were able to relax just a few internal constraints and get
>> the system to fit the design. He did comment that my design was probably
>> the fullest design he had seen in the wild, we had grown to about 95%
>> logic utilization.
>
> Yeah, that's pretty full.  I start to worry around 80%, but I've never
> actually had one fail to route other than the ones I tried to help by
> doing placement, lol.
>

They suggest that you consider 75-80% to be "Full". This design started 
in the 70% level but we were adding capability to the system and the 
density grew. (And were already using the largest chip for the 
footprint). Our next step was to redo the board and get the usage back 
down. When we hit the issue we had a mostly working design but were 
fixing the one last bug, and that was when the fitter threw its fit.

Article: 158147
Subject: Re: Finally! A Completely Open Complete FPGA Toolchain
From: rickman <gnuarm@gmail.com>
Date: Tue, 18 Aug 2015 11:35:48 -0400
Links: << >>  << T >>  << A >>
On 8/15/2015 8:32 AM, Richard Damon wrote:
> On 8/14/15 10:59 PM, rickman wrote:
>> On 8/14/2015 9:32 PM, Richard Damon wrote:
>>>
>>> My experience is that you get to see what location a given piece of
>>> logic, and which channels it travels. You do NOT see which particular
>>> wire in that channel is being used. In general, each logic cell does not
>>> have routing to every wire in that channel, and every wire does not have
>>> access to every cross wire. These details tend to be the secret sauce,
>>> as when they do it well, you aren't supposed to notice the incomplete
>>> connections.
>>
>> Don't they still have the chip editor?  That *must* show everything of
>> importance.
>
> The chip editors tend to just show the LOGIC resources, not the details
> of the routing resources. The manufactures tend to do a good job of
> giving the detail of the logic blocks you are working with, as this is
> the part of the design you tend to specify. Routing on the other hand
> tends to not be something you care about, just that the routing 'works'.
> When they have done a good job at designing the routing you don't notice
> it, but there have been cases where the routing turned out not quite
> flexible enough and you notice that you can't fill the device as well
> before hitting routing issues.

I'm not sure what details of the routing the chip editors leave out. 
You only need to know what is connected to what, through what and what 
the delays for all those cases are.  Other than that, the routing does 
just "work".


>>> I have had to work with the factory on things like this. I had a very
>>> full FPGA and needed to make a small change. With the change I had some
>>> over clogged routing, but if I removed all internal constraints the
>>> fitter couldn't find a fit. Working with someone who did know the
>>> details, we were able to relax just a few internal constraints and get
>>> the system to fit the design. He did comment that my design was probably
>>> the fullest design he had seen in the wild, we had grown to about 95%
>>> logic utilization.
>>
>> Yeah, that's pretty full.  I start to worry around 80%, but I've never
>> actually had one fail to route other than the ones I tried to help by
>> doing placement, lol.
>>
>
> They suggest that you consider 75-80% to be "Full". This design started
> in the 70% level but we were adding capability to the system and the
> density grew. (And were already using the largest chip for the
> footprint). Our next step was to redo the board and get the usage back
> down. When we hit the issue we had a mostly working design but were
> fixing the one last bug, and that was when the fitter threw its fit.

The "full" utilization number is approximate because it depends on the 
details of the design.  Some designs can get to higher utilization 
numbers, others less.  As a way of pointing out that the routing is the 
part of the chip that uses the most space while the logic is smaller, 
Xilinx sales people used to say, "We sell you the routing and give you 
the logic for free."  The point is the routing usually limits your 
design rather than the logic.  If you want to be upset about utilization 
numbers, ask them how much of your routing gets used!  It's *way* below 
80%.

-- 

Rick

Article: 158148
Subject: Re: Finally! A Completely Open Complete FPGA Toolchain
From: KJ <kkjennings@sbcglobal.net>
Date: Tue, 18 Aug 2015 11:21:04 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Tuesday, August 18, 2015 at 11:35:55 AM UTC-4, rickman wrote:
> 
> I'm not sure what details of the routing the chip editors leave out. 
> You only need to know what is connected to what, through what and what 
> the delays for all those cases are.

If you're trying to implement an open source toolchain you would likely need to know *how* to specify those connections via the programming bitstream.

Kevin

Article: 158149
Subject: Re: Finally! A Completely Open Complete FPGA Toolchain
From: Richard Damon <Richard@Damon-Family.org>
Date: Tue, 18 Aug 2015 21:40:27 -0400
Links: << >>  << T >>  << A >>
On 8/18/15 11:35 AM, rickman wrote:
> On 8/15/2015 8:32 AM, Richard Damon wrote:
>>
>> The chip editors tend to just show the LOGIC resources, not the details
>> of the routing resources. The manufactures tend to do a good job of
>> giving the detail of the logic blocks you are working with, as this is
>> the part of the design you tend to specify. Routing on the other hand
>> tends to not be something you care about, just that the routing 'works'.
>> When they have done a good job at designing the routing you don't notice
>> it, but there have been cases where the routing turned out not quite
>> flexible enough and you notice that you can't fill the device as well
>> before hitting routing issues.
>
> I'm not sure what details of the routing the chip editors leave out. You
> only need to know what is connected to what, through what and what the
> delays for all those cases are.  Other than that, the routing does just
> "work".
>

Look closely. The chip editor will normally show you the exact logic 
element you are using with a precise location. The output will then go 
out into a routing channel and on the the next logic logic cell(s) that 
it goes to. It may even show you the the various rows and columns of 
routing it is going through. Those rows and columns are made of a 
(large) number of distinct wires with routing resources connecting 
outputs to select lines and select lines being brought into the next 
piece of routing/logic. Which wire is being used will not be indicated, 
nor are all the wires interchangeable, so which wire can matter for 
fitting. THIS is the missing information.
>
>>>> I have had to work with the factory on things like this. I had a very
>>>> full FPGA and needed to make a small change. With the change I had some
>>>> over clogged routing, but if I removed all internal constraints the
>>>> fitter couldn't find a fit. Working with someone who did know the
>>>> details, we were able to relax just a few internal constraints and get
>>>> the system to fit the design. He did comment that my design was
>>>> probably
>>>> the fullest design he had seen in the wild, we had grown to about 95%
>>>> logic utilization.
>>>
>>> Yeah, that's pretty full.  I start to worry around 80%, but I've never
>>> actually had one fail to route other than the ones I tried to help by
>>> doing placement, lol.
>>>
>>
>> They suggest that you consider 75-80% to be "Full". This design started
>> in the 70% level but we were adding capability to the system and the
>> density grew. (And were already using the largest chip for the
>> footprint). Our next step was to redo the board and get the usage back
>> down. When we hit the issue we had a mostly working design but were
>> fixing the one last bug, and that was when the fitter threw its fit.
>
> The "full" utilization number is approximate because it depends on the
> details of the design.  Some designs can get to higher utilization
> numbers, others less.  As a way of pointing out that the routing is the
> part of the chip that uses the most space while the logic is smaller,
> Xilinx sales people used to say, "We sell you the routing and give you
> the logic for free."  The point is the routing usually limits your
> design rather than the logic.  If you want to be upset about utilization
> numbers, ask them how much of your routing gets used!  It's *way* below
> 80%.
>
And this is why the keep the real details of the routing proprietary. 
(Not to keep you from getting upset) The serious design work goes into 
figuring out how much they really need per cell. If they could figure 
out a better allocation that let them cut the routing per cell by 10%, 
they could give you 10% more logic for free. If they goof and provide 
too little routing, you see the resources that you were sold (since they 
advertize the logic capability) as being wasted by some 'dumb design 
limitation'. There have been families that got black eyes of having 
routing problems, and thus should be avoided for 'serious' work.



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