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 158900

Article: 158900
Subject: Re: FPGA boards in egypt
From: Jecel <jecel@merlintec.com>
Date: Mon, 16 May 2016 10:35:52 -0700 (PDT)
Links: << >>  << T >>  << A >>
Rick,

> BTW, I can't find any reference in the data sheet to SP601 or SP605. 
> What does that mean?

They are complete boards for the Spartan 6 FPGA:

http://www.xilinx.com/products/boards-and-kits/ek-s6-sp601-g.html ($300)

http://www.xilinx.com/products/boards-and-kits/ek-s6-sp605-g.html ($417)

-- Jecel

Article: 158901
Subject: Re: FPGA boards in egypt
From: rickman <gnuarm@gmail.com>
Date: Mon, 16 May 2016 14:34:45 -0400
Links: << >>  << T >>  << A >>
On 5/16/2016 1:35 PM, Jecel wrote:
> Rick,
>
>> BTW, I can't find any reference in the data sheet to SP601 or SP605.
>> What does that mean?
>
> They are complete boards for the Spartan 6 FPGA:
>
> http://www.xilinx.com/products/boards-and-kits/ek-s6-sp601-g.html ($300)
>
> http://www.xilinx.com/products/boards-and-kits/ek-s6-sp605-g.html ($417)

Yes, I eventually figured that out, but thanks for the reply.

Xilinx boards aren't so cheap, but I guess they have a lot more than 
just the FPGA.

-- 

Rick C

Article: 158902
Subject: Re: Constraining data to out-of-phase clocks
From: Tim Wescott <seemywebsite@myfooter.really>
Date: Mon, 16 May 2016 16:01:48 -0500
Links: << >>  << T >>  << A >>
On Mon, 16 May 2016 13:23:12 -0400, rickman wrote:

> On 5/16/2016 12:32 PM, Tim Wescott wrote:
>> On Mon, 16 May 2016 15:58:05 +0000, Rob Gaddi wrote:
>>
>>> BobH wrote:
>>>
>>>> On 05/13/2016 04:18 PM, Rob Gaddi wrote:
>>>>> I've got a project coming up in which one of the things I'm going to
>>>>> need to do is take in the 1 PPS output from a GPS receiver and align
>>>>> it to the 100 MHz frequency reference clock.
>>>>>
>>>>> The problem here is that the phase relationship is static but
>>>>> undefined.
>>>>>   There's plenty of time somewhere to not violate the setup time,
>>>>>   but I
>>>>> have to find where it is.
>>>>>
>>>>> My thought had been to use one of the FPGA PLLs to spin up 8 phases
>>>>> (well, 4 and 4 bar) of the 100 MHz clock and capture the PPS signal
>>>>> on all of them. Then resychronize those to the 0° clock, read the
>>>>> thermometer code, and figure out what the data phase is. Then I can
>>>>> use the value opposite that and know I've got enough margin to park
>>>>> a semitrailer in.
>>>>>
>>>>> All well and good, except it dawns on me that I don't know how to
>>>>> convince the tools to make timing for that.  Somehow my SDC file has
>>>>> to call for running the input signal from the input pin to 8 flops
>>>>> such that the clock/data skew is less than 1 ns.
>>>>>
>>>>> Anyone know how I'd do such a thing?  Altera seems to support
>>>>> set_max_skew, which might do it if I can disentangle the arcana of
>>>>> the syntax from
>>>>> http://quartushelp.altera.com/14.1/mergedProjects/tafs/tafs/
>> tcl_pkg_sdc_ext_ver_1.0_cmd_set_max_skew.htm
>>>>> But I'm not necessarily wedded to Altera on this project.
>>>>>
>>>>>
>>>> The 1PPS signals out of the GPS receivers that I have seen, advertise
>>>> 50nS accuracy. Your 100MHz clock has a period of 10nS. From what I
>>>> understand of your project, I would just put the 1PPS signal in
>>>> through a couple of sync FF's and then compensate for an assumed
>>>> delay of 2 clock cycles in the application of the sync'ed 1PPS signal
>>>> downstream.
>>>>
>>>>
>>> You know how sometimes when you get started on a project, and you get
>>> some assumptions so firmly in your head that you don't even realize
>>> that they're just assumptions?  I had a substantially better opinion
>>> of the jitter on the 1 PPS than is actually warranted.  There are a
>>> _COUPLE_ of receivers out there with 1 PPS jitter down to 10 ns (RMS),
>>> but for the most part you're entirely correct.  And even at 10,
>>> there's no static relationship against a PLL-locked 100 MHz; it's just
>>> every pulse for itself.
>>>
>>> You'd think with as many times as I've learned that lesson, one of
>>> these times it would stick.
>>>
>>>> The phase relationship between the 1PPS input and the local 100MHz
>>>> clock won't be all that static unless you phase lock the 100MHz clock
>>>> to the 1PPS. Even an exotic local oscillator is going to drift around
>>>> with time and temperature compared to the 1PPS.
>>>>
>>>>
>>> Now that's a question I have no idea how to resolve.  Is the exotic LO
>>> (let's assume cesium for fun) drifting and the PPS stable, or is it
>>> (I'd guess) that no matter how stable the LO that the PPS is walking
>>> around?
>>>
>>> Making claims of objective truth on these timescales is hard.
>>
>> I'm pretty sure that it would be the 1PPS walking around, but walking
>> around with an average error of zero, or at least zero somewhere inside
>> the receiver, with a fixed offset to the spigot on the box, and another
>> fixed offset from that spigot to your chip.  So your "objective truth"
>> is that the average time error is zero, or at least some knowable,
>> calibrateable constant.
>>
>> GPS gets a message from each of a bunch of satellites that basically
>> add up to "this is what time it is and this is where I am".  If the GPS
>> receiver knew what time it was, it could take three such messages and
>> determine where it is (because there are three spatial dimensions, so
>> it needs three equations to solve for three unknowns).  But the GPS
>> receiver doesn't know what time it is, so it has to solve for time,
>> too.
>>
>> So a GPS receiver is either going to smooth the 1PPS itself, thereby
>> running the chance of making it worse, and requiring it to have a
>> pretty good time base, or it's going to not smooth the 1PPS, and
>> instead just use the most recent GPS time/position solution to decide
>> when to pop off the 1PPS pulse.  If it doesn't smooth the 1PPS, then
>> you can expect a time error that's commensurate with the usual GPS
>> position error of 10 meters or so (100 meters if the defense department
>> decides to turn selective availability on, and no guarantees that in
>> time of war they won't).  10 meters works out to 30ns, so...
> 
> I don't know for sure, but I find it hard to believe they would output
> the 1 PPS based solely on one measurement each.  While the 10 meter may
> often constrain the accuracy of any one calculation, it is probabilistic
> and can have a much larger actual error for a short amount of time.
> While they may not be doing something equivalent to a PLL for the time,
> I expect they are at least using some form of weighted average for
> calculating the 1 PPS signal.
> 
> I had a GPS that would receive the signals ok in my house and connected
> it to a utility that would map the location over time on an XY display.
>   I saw it walk off the property maybe once per day and come back within
> a minute or less.  That would be more like 50 meters.  I've heard of
> shipwrecks due to a loss of accuracy caused by poor constellations. That
> has to be a lot more than 50 meters.

There are some crowded harbors where the margin of error is less than 
that.  My master's thesis was building a data-link receiver for the US 
Coast Guard's then-experimental differential GPS service*.  At the time 
selective availability was sometimes on ("SA" -- they turned it on for 
Gulf War #1, AFAIK), and with SA on you could only get a 90% CEP of 100 
meters.  With differential GPS you could get it down to less than 10m.

I don't know if it's done, but when I was in grad school (and paying 
attention, thanks to my prof) they were also talking about using 
pseudolites, which are basically low-powered GPS satellites sitting on 
the ground, doing what GPS satellites do.  They augment the constellation 
in places where it Really Matters (like narrow harbor mouths).  A minute 
of web research tells me that they're out there, but not whether they're 
in common use.

* Everyone sees that and thinks I'm a microwave designer.  No.  The data 
link was operating at their radiobeacon frequencies, around 300kHz.  It's 
a different world altogether, with entirely different propagation and 
even noise characteristics than microwaves.  It did, however, give me an 
early appreciation for the fact that all the nice theory you're taught is 
based on whatever you can do when the math is easy, not necessarily what 
happens when you start from real-world phenomenon and try to work things 
out from there.

-- 

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

I'm looking for work -- see my website!

Article: 158903
Subject: Re: Constraining data to out-of-phase clocks
From: BobH <wanderingmetalhead.nospam.please@yahoo.com>
Date: Mon, 16 May 2016 16:31:24 -0700
Links: << >>  << T >>  << A >>
On 05/16/2016 08:58 AM, Rob Gaddi wrote:
>> BobH wrote:
> On 05/13/2016 04:18 PM, Rob Gaddi wrote:

>> The phase relationship between the 1PPS input and the local 100MHz clock
>> won't be all that static unless you phase lock the 100MHz clock to the
>> 1PPS. Even an exotic local oscillator is going to drift around with time
>> and temperature compared to the 1PPS.
>>
>
> Now that's a question I have no idea how to resolve.  Is the exotic
> LO (let's assume cesium for fun) drifting and the PPS stable, or is it
> (I'd guess) that no matter how stable the LO that the PPS is walking
> around?

I expect that the 1PPS out of the GPS receiver will be based on some 
high frequency clock, My suspicion is that it is a 20MHz clock, hence 
the 50nS jitter.

My guess is that both clocks are going to wander with respect to each 
other, and if you use the simple 2 sync FF's you might get better 
results if they do wander. If the clocks are almost synchronous, you 
will get times when the input will fail to meet the setup for 
significant durations and may get missed clock edges in bunches, where 
if the clocks were not too close, you would only get an occasional 
missed clock edge. This is speculation on my part though.


> Making claims of objective truth on these timescales is hard.

For Sure! Everything about GPS is handled statistically though, so it 
just defines a probable window for it.

Good Luck,
BobH


Article: 158904
Subject: Re: Constraining data to out-of-phase clocks
From: BobH <wanderingmetalhead.nospam.please@yahoo.com>
Date: Mon, 16 May 2016 16:40:23 -0700
Links: << >>  << T >>  << A >>
On 05/16/2016 09:32 AM, Tim Wescott wrote:
> GPS gets a message from each of a bunch of satellites that basically add
> up to "this is what time it is and this is where I am".  If the GPS
> receiver knew what time it was, it could take three such messages and
> determine where it is (because there are three spatial dimensions, so it
> needs three equations to solve for three unknowns).  But the GPS receiver
> doesn't know what time it is, so it has to solve for time, too.
>
The fancy GPS "Timing Receivers" allow you to lock the position value to 
a surveyed value (or a few day average of the position) and then you get 
a more accurate time calculation with fewer sats.

Unless you are in a deep urban canyon or a real canyon, 4 sats should be 
pretty easy to see for a full 3D fix with time. More sats lets the 
receiver software pick and choose which ones to use for the lowest 
residual error on the calculations.

BobH


Article: 158905
Subject: Re: Constraining data to out-of-phase clocks
From: rickman <gnuarm@gmail.com>
Date: Mon, 16 May 2016 19:43:40 -0400
Links: << >>  << T >>  << A >>
On 5/16/2016 7:40 PM, BobH wrote:
> On 05/16/2016 09:32 AM, Tim Wescott wrote:
>> GPS gets a message from each of a bunch of satellites that basically add
>> up to "this is what time it is and this is where I am".  If the GPS
>> receiver knew what time it was, it could take three such messages and
>> determine where it is (because there are three spatial dimensions, so it
>> needs three equations to solve for three unknowns).  But the GPS receiver
>> doesn't know what time it is, so it has to solve for time, too.
>>
> The fancy GPS "Timing Receivers" allow you to lock the position value to
> a surveyed value (or a few day average of the position) and then you get
> a more accurate time calculation with fewer sats.
>
> Unless you are in a deep urban canyon or a real canyon, 4 sats should be
> pretty easy to see for a full 3D fix with time. More sats lets the
> receiver software pick and choose which ones to use for the lowest
> residual error on the calculations.

It's not just how many sats, but where they are.  Best if they are not 
close together but rather spread around most of the sky.

-- 

Rick C

Article: 158906
Subject: Re: Constraining data to out-of-phase clocks
From: BobH <wanderingmetalhead.nospam.please@yahoo.com>
Date: Mon, 16 May 2016 18:16:46 -0700
Links: << >>  << T >>  << A >>
On 05/16/2016 04:43 PM, rickman wrote:
> On 5/16/2016 7:40 PM, BobH wrote:
>> On 05/16/2016 09:32 AM, Tim Wescott wrote:
>>> GPS gets a message from each of a bunch of satellites that basically add
>>> up to "this is what time it is and this is where I am".  If the GPS
>>> receiver knew what time it was, it could take three such messages and
>>> determine where it is (because there are three spatial dimensions, so it
>>> needs three equations to solve for three unknowns).  But the GPS
>>> receiver
>>> doesn't know what time it is, so it has to solve for time, too.
>>>
>> The fancy GPS "Timing Receivers" allow you to lock the position value to
>> a surveyed value (or a few day average of the position) and then you get
>> a more accurate time calculation with fewer sats.
>>
>> Unless you are in a deep urban canyon or a real canyon, 4 sats should be
>> pretty easy to see for a full 3D fix with time. More sats lets the
>> receiver software pick and choose which ones to use for the lowest
>> residual error on the calculations.
>
> It's not just how many sats, but where they are.  Best if they are not
> close together but rather spread around most of the sky.
>
True. That is why elevation accuracy is the worst axis. It is really 
hard to get a signal from a satellite below you!

BobH

Article: 158907
Subject: Re: Problem if compilation order in OOC compilations in Xilinx Vivado
From: wzab01@gmail.com
Date: Mon, 16 May 2016 23:11:06 -0700 (PDT)
Links: << >>  << T >>  << A >>
W dniu pi=C4=85tek, 13 maja 2016 18:25:01 UTC+2 u=C5=BCytkownik rickman nap=
isa=C5=82:
> On 5/13/2016 9:47 AM, wzab01@gmail.com wrote:
> > Hi,
> >
> > Has anybody in this group faced the problem of incorrect compilation or=
der of blocks selected for Out-of-context (OOC) compilation?
> > It works correctly in case of blocks converted into packaged IP-cores.
> > However very often in the huge projects I'm dealing with (e.g. using th=
e 70% of Virtex 7 xc7vx690tffg1927) I want to split the design into blocks =
synthesized separately without packaging them.
> >
> > It allows to avoid resynthesizing of the whole design (which takes from=
 5 to 8 hours) when only one of the blocks is modified.
> >
> > The reason to not package them is the fact that the design is implement=
ed in high level VHDL. The ports of the components are usually implemented =
as records describing the data structures. The current packaging standards =
based oon IP-XACT do not support such ports.
> >
> > Anyway, I'm quite happy with using OOC synthesis for my components (Yes=
, you can do it even for blocks with ports of user defined types as long as=
 you provide your own stubs instead of letting Vivado to generate them auto=
matically).
> > However, there is one HUGE problem.
> >
> > The "OOC Module Runs" are performed perfectly, and the separate modules=
 are synthesized correctly, but as soon as I start the main (usually "synth=
_1") run, all OOC runs are set "out-of-date" and restarted. This time they =
are synthesized using incorrect compilation order which results in compilat=
ion errors (typically entities using types and constants defined in the pac=
kages are compiled before those packages).
> >
> > After some research I've found an work-around, which can be even implem=
ented in the Tcl script.
> > I've described the whole problem together with a "bug reproducer" and w=
orkaround on the Xilinx forum - https://forums.xilinx.com/t5/Synthesis/Viva=
do-incorrect-automatic-compilation-order-in-OOC-synthesis/m-p/698402#M18253=
 but up to know I didn't get any answer from Xilinx.
> >
> > I'm quite surprised, that no one alse has reported this rather serious =
bug before.
> >
> > AFAIK it was present at least in all 2015.x and 2016.1 versions. (I don=
't know whether it was in the earlier versions, as it was begining of the 2=
015, when I had to split my design into OOC blocks).
>=20
> I haven't used the Xilinx tools in years.  But the Lattice tools I have=
=20
> used allow you to specify the order of compilation for files.  I=20
> routinely have to specify which files are libraries and which are to be=
=20
> compiled later.  Does Xilinx give you a way to flag libraries?  I can't=
=20
> imagine it couldn't figure out the file dependencies of libraries.
>=20
> I suspect you are working in a different way where you can group files=20
> into blocks at a higher level.
>=20
> --=20
>=20
> Rick C

Hi,

Yes, usually Xilinx Vivado automatically finds the correct order of compila=
tion.
The problem is that in that particular situation it does it in the incorrec=
t way (in fact it knows the right order, but it doesn't use it)

It is possible to define the compilation order manually (but it can't be do=
ne for designs using the Block Design components).
Additionally the manual setting of compilation order is not a viable soluti=
on with designs consisting of ca. 100 source files...

With best regards,
Wojtek

Article: 158908
Subject: Re: Constraining data to out-of-phase clocks
From: Tim Wescott <tim@seemywebsite.com>
Date: Tue, 17 May 2016 19:52:46 -0500
Links: << >>  << T >>  << A >>
On Mon, 16 May 2016 13:23:12 -0400, rickman wrote:

> On 5/16/2016 12:32 PM, Tim Wescott wrote:
>> On Mon, 16 May 2016 15:58:05 +0000, Rob Gaddi wrote:
>>
>>> BobH wrote:
>>>
>>>> On 05/13/2016 04:18 PM, Rob Gaddi wrote:
>>>>> I've got a project coming up in which one of the things I'm going to
>>>>> need to do is take in the 1 PPS output from a GPS receiver and align
>>>>> it to the 100 MHz frequency reference clock.
>>>>>
>>>>> The problem here is that the phase relationship is static but
>>>>> undefined.
>>>>>   There's plenty of time somewhere to not violate the setup time,
>>>>>   but I
>>>>> have to find where it is.
>>>>>
>>>>> My thought had been to use one of the FPGA PLLs to spin up 8 phases
>>>>> (well, 4 and 4 bar) of the 100 MHz clock and capture the PPS signal
>>>>> on all of them. Then resychronize those to the 0° clock, read the
>>>>> thermometer code, and figure out what the data phase is. Then I can
>>>>> use the value opposite that and know I've got enough margin to park
>>>>> a semitrailer in.
>>>>>
>>>>> All well and good, except it dawns on me that I don't know how to
>>>>> convince the tools to make timing for that.  Somehow my SDC file has
>>>>> to call for running the input signal from the input pin to 8 flops
>>>>> such that the clock/data skew is less than 1 ns.
>>>>>
>>>>> Anyone know how I'd do such a thing?  Altera seems to support
>>>>> set_max_skew, which might do it if I can disentangle the arcana of
>>>>> the syntax from
>>>>> http://quartushelp.altera.com/14.1/mergedProjects/tafs/tafs/
>> tcl_pkg_sdc_ext_ver_1.0_cmd_set_max_skew.htm
>>>>> But I'm not necessarily wedded to Altera on this project.
>>>>>
>>>>>
>>>> The 1PPS signals out of the GPS receivers that I have seen, advertise
>>>> 50nS accuracy. Your 100MHz clock has a period of 10nS. From what I
>>>> understand of your project, I would just put the 1PPS signal in
>>>> through a couple of sync FF's and then compensate for an assumed
>>>> delay of 2 clock cycles in the application of the sync'ed 1PPS signal
>>>> downstream.
>>>>
>>>>
>>> You know how sometimes when you get started on a project, and you get
>>> some assumptions so firmly in your head that you don't even realize
>>> that they're just assumptions?  I had a substantially better opinion
>>> of the jitter on the 1 PPS than is actually warranted.  There are a
>>> _COUPLE_ of receivers out there with 1 PPS jitter down to 10 ns (RMS),
>>> but for the most part you're entirely correct.  And even at 10,
>>> there's no static relationship against a PLL-locked 100 MHz; it's just
>>> every pulse for itself.
>>>
>>> You'd think with as many times as I've learned that lesson, one of
>>> these times it would stick.
>>>
>>>> The phase relationship between the 1PPS input and the local 100MHz
>>>> clock won't be all that static unless you phase lock the 100MHz clock
>>>> to the 1PPS. Even an exotic local oscillator is going to drift around
>>>> with time and temperature compared to the 1PPS.
>>>>
>>>>
>>> Now that's a question I have no idea how to resolve.  Is the exotic LO
>>> (let's assume cesium for fun) drifting and the PPS stable, or is it
>>> (I'd guess) that no matter how stable the LO that the PPS is walking
>>> around?
>>>
>>> Making claims of objective truth on these timescales is hard.
>>
>> I'm pretty sure that it would be the 1PPS walking around, but walking
>> around with an average error of zero, or at least zero somewhere inside
>> the receiver, with a fixed offset to the spigot on the box, and another
>> fixed offset from that spigot to your chip.  So your "objective truth"
>> is that the average time error is zero, or at least some knowable,
>> calibrateable constant.
>>
>> GPS gets a message from each of a bunch of satellites that basically
>> add up to "this is what time it is and this is where I am".  If the GPS
>> receiver knew what time it was, it could take three such messages and
>> determine where it is (because there are three spatial dimensions, so
>> it needs three equations to solve for three unknowns).  But the GPS
>> receiver doesn't know what time it is, so it has to solve for time,
>> too.
>>
>> So a GPS receiver is either going to smooth the 1PPS itself, thereby
>> running the chance of making it worse, and requiring it to have a
>> pretty good time base, or it's going to not smooth the 1PPS, and
>> instead just use the most recent GPS time/position solution to decide
>> when to pop off the 1PPS pulse.  If it doesn't smooth the 1PPS, then
>> you can expect a time error that's commensurate with the usual GPS
>> position error of 10 meters or so (100 meters if the defense department
>> decides to turn selective availability on, and no guarantees that in
>> time of war they won't).  10 meters works out to 30ns, so...
> 
> I don't know for sure, but I find it hard to believe they would output
> the 1 PPS based solely on one measurement each.
<snip>

At least one of the data sheets implied exactly that.  I could see having 
a philosophy of "do our best from moment to moment, and let the customer 
make _their_ best from that".  As a sometime-customer of places that want 
to give me highly-cooked data, I can even appreciate the sentiment.

-- 
Tim Wescott
Control systems, embedded software and circuit design
I'm looking for work!  See my website if you're interested
http://www.wescottdesign.com

Article: 158909
Subject: Multi-port memory
From: Ilya Kalistru <stebanoid@gmail.com>
Date: Sat, 21 May 2016 09:28:03 -0700 (PDT)
Links: << >>  << T >>  << A >>
In this article 
http://fpga.org/wp-content/uploads/2016/05/grvi_phalanx_fccm2016.pdf
on the second page there's a description of the memory architecture. A can't wrap around my head how did they configure 8 BRAMs to a 32KB memory with 12 independent ports. Can anybody explain this to me?

Article: 158910
Subject: Re: Multi-port memory
From: rickman <gnuarm@gmail.com>
Date: Sat, 21 May 2016 12:48:37 -0400
Links: << >>  << T >>  << A >>
On 5/21/2016 12:28 PM, Ilya Kalistru wrote:
> In this article
> http://fpga.org/wp-content/uploads/2016/05/grvi_phalanx_fccm2016.pdf
> on the second page there's a description of the memory architecture.
> A can't wrap around my head how did they configure 8 BRAMs to a 32KB
> memory with 12 independent ports. Can anybody explain this to me?

The 32 kB CRAM has four ports, but each port only accesses a quarter of 
the memory.  If each port were able to access the full memory there 
would be no need for the crossbar switch.  So really the CRAM is four 
separate 8 kB RAMs.  Or did I miss something?

-- 

Rick C

Article: 158911
Subject: Re: Multi-port memory
From: Tim Wescott <tim@seemywebsite.com>
Date: Sat, 21 May 2016 12:39:47 -0500
Links: << >>  << T >>  << A >>
On Sat, 21 May 2016 09:28:03 -0700, Ilya Kalistru wrote:

> In this article
> http://fpga.org/wp-content/uploads/2016/05/grvi_phalanx_fccm2016.pdf on
> the second page there's a description of the memory architecture. A
> can't wrap around my head how did they configure 8 BRAMs to a 32KB
> memory with 12 independent ports. Can anybody explain this to me?

I only skimmed that paper so my impression could be wrong, but it seemed 
that the buzzword/content ratio was fairly high.  In such cases, close 
examination of questionable content -- when it doesn't lead to outright 
evasion -- often leads to finding out they're doing something 
predictable, ordinary, and not too astonishing.

If I recall correctly, the Xilinx BRAMs are already dual-port.  The 
predictable, ordinary, and not too astonishing way that I'd do what they 
describe would be to design an arbitrating interface to the BRAM blocks 
in such a manner that any two accesses to any one BRAM would be "perfect" 
dual-port, but simultaneous accesses beyond two would generate "not 
ready" signals.

I might even design it so that while there are 12 ports, each port would 
have preferred access to just one or two BRAMs, with accesses to BRAMs 
that are "further afield" (conceptually if not physically on the chip) 
would take longer.

You could possibly speed this up by stacking up any write requests to be 
done in slack time, but you'd have to do it in a consistent manner -- you 
wouldn't a subsequent read of old data, for instance.

So, basically, you'd do the same thing as you'd do if you were making a 
"dual port" RAM with a controller and a bunch of single-port RAM chips, 
only more so.

-- 
Tim Wescott
Control systems, embedded software and circuit design
I'm looking for work!  See my website if you're interested
http://www.wescottdesign.com

Article: 158912
Subject: Re: Multi-port memory
From: Tim Wescott <tim@seemywebsite.com>
Date: Sat, 21 May 2016 12:43:22 -0500
Links: << >>  << T >>  << A >>
On Sat, 21 May 2016 12:39:47 -0500, Tim Wescott wrote:

> On Sat, 21 May 2016 09:28:03 -0700, Ilya Kalistru wrote:
> 
>> In this article
>> http://fpga.org/wp-content/uploads/2016/05/grvi_phalanx_fccm2016.pdf on
>> the second page there's a description of the memory architecture. A
>> can't wrap around my head how did they configure 8 BRAMs to a 32KB
>> memory with 12 independent ports. Can anybody explain this to me?
> 
> I only skimmed that paper so my impression could be wrong, but it seemed
> that the buzzword/content ratio was fairly high.  In such cases, close
> examination of questionable content -- when it doesn't lead to outright
> evasion -- often leads to finding out they're doing something
> predictable, ordinary, and not too astonishing.
> 
> If I recall correctly, the Xilinx BRAMs are already dual-port.  The
> predictable, ordinary, and not too astonishing way that I'd do what they
> describe would be to design an arbitrating interface to the BRAM blocks
> in such a manner that any two accesses to any one BRAM would be
> "perfect"
> dual-port, but simultaneous accesses beyond two would generate "not
> ready" signals.
> 
> I might even design it so that while there are 12 ports, each port would
> have preferred access to just one or two BRAMs, with accesses to BRAMs
> that are "further afield" (conceptually if not physically on the chip)
> would take longer.
> 
> You could possibly speed this up by stacking up any write requests to be
> done in slack time, but you'd have to do it in a consistent manner --
> you wouldn't a subsequent read of old data, for instance.
> 
> So, basically, you'd do the same thing as you'd do if you were making a
> "dual port" RAM with a controller and a bunch of single-port RAM chips,
> only more so.

I should mention -- for the most part I'm not an FPGA guy.  I'm circuit 
design and software, with enough FPGA chops to do simple stuff.  I have 
done FPGA projects that have left the customer happy, but I've done more 
work that involves credibly _threatening_ (one says "offering" with an 
ingratiating smile for maximum effect) to write some Verilog or VHDL.  
Given a reasonably competent and territorial FPGA guy, this usually 
prompts a response of "here, Tim, let me take that off your hands".

-- 
Tim Wescott
Control systems, embedded software and circuit design
I'm looking for work!  See my website if you're interested
http://www.wescottdesign.com

Article: 158913
Subject: Re: Multi-port memory
From: Ilya Kalistru <stebanoid@gmail.com>
Date: Sat, 21 May 2016 11:51:04 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Saturday, May 21, 2016 at 7:48:43 PM UTC+3, rickman wrote:
> On 5/21/2016 12:28 PM, Ilya Kalistru wrote:
> > In this article
> > http://fpga.org/wp-content/uploads/2016/05/grvi_phalanx_fccm2016.pdf
> > on the second page there's a description of the memory architecture.
> > A can't wrap around my head how did they configure 8 BRAMs to a 32KB
> > memory with 12 independent ports. Can anybody explain this to me?
>=20
> The 32 kB CRAM has four ports, but each port only accesses a quarter of=
=20
> the memory.  If each port were able to access the full memory there=20
> would be no need for the crossbar switch.  So really the CRAM is four=20
> separate 8 kB RAMs.  Or did I miss something?
>=20
> --=20
>=20
> Rick C

yes. That makes sense. I just thought that if they mentioned pipeline halti=
ng in the case of simultaneous access to 2:1 mux, that means that there is =
no arbitrating in 4 ports of memory. But now I see that in the sentence abo=
ut halting they don't mention 2:1 mux. It can be about this 4 ports too.

Article: 158914
Subject: Re: Multi-port memory
From: rickman <gnuarm@gmail.com>
Date: Sat, 21 May 2016 23:32:59 -0400
Links: << >>  << T >>  << A >>
On 5/21/2016 1:43 PM, Tim Wescott wrote:
>
> I should mention -- for the most part I'm not an FPGA guy.  I'm circuit
> design and software, with enough FPGA chops to do simple stuff.  I have
> done FPGA projects that have left the customer happy, but I've done more
> work that involves credibly _threatening_ (one says "offering" with an
> ingratiating smile for maximum effect) to write some Verilog or VHDL.
> Given a reasonably competent and territorial FPGA guy, this usually
> prompts a response of "here, Tim, let me take that off your hands".

I think it's more like the FPGA guy feels you are offensive to the art 
of FPGAs.  Maybe not truly dangerous, but not the sort of thing an FPGA 
guy wants to think about.  I haven't worked with you obviously, I'm just 
going from your description.  :)

Actually I just finished a simple presentation on test benches for an 
FPGA workshop being given next week.  The guy doing it is providing an 
8080 core that he is testing by loading a Forth interpreter into the CPU 
memory.  I ran a testbench driven by a text command file and in the 
simple test I put together I found a bug in the increment/decrement 
commands.  I mentioned that in my writeup since that is a good 
illustration of using testbenches.

-- 

Rick C

Article: 158915
Subject: Re: Multi-port memory
From: Tim Wescott <tim@seemywebsite.com>
Date: Sun, 22 May 2016 00:32:03 -0500
Links: << >>  << T >>  << A >>
On Sat, 21 May 2016 23:32:59 -0400, rickman wrote:

> On 5/21/2016 1:43 PM, Tim Wescott wrote:
>>
>> I should mention -- for the most part I'm not an FPGA guy.  I'm circuit
>> design and software, with enough FPGA chops to do simple stuff.  I have
>> done FPGA projects that have left the customer happy, but I've done
>> more work that involves credibly _threatening_ (one says "offering"
>> with an ingratiating smile for maximum effect) to write some Verilog or
>> VHDL. Given a reasonably competent and territorial FPGA guy, this
>> usually prompts a response of "here, Tim, let me take that off your
>> hands".
> 
> I think it's more like the FPGA guy feels you are offensive to the art
> of FPGAs.  Maybe not truly dangerous, but not the sort of thing an FPGA
> guy wants to think about.  I haven't worked with you obviously, I'm just
> going from your description.  :)

You're probably right.  I believe that I have a pretty good grasp of 
what's possible with FPGAs, but I'm not an experienced or even a hugely 
interested practitioner.

-- 
Tim Wescott
Control systems, embedded software and circuit design
I'm looking for work!  See my website if you're interested
http://www.wescottdesign.com

Article: 158916
Subject: Re: Multi-port memory
From: rickman <gnuarm@gmail.com>
Date: Sun, 22 May 2016 06:37:31 -0400
Links: << >>  << T >>  << A >>
On 5/22/2016 1:32 AM, Tim Wescott wrote:
> On Sat, 21 May 2016 23:32:59 -0400, rickman wrote:
>
>> On 5/21/2016 1:43 PM, Tim Wescott wrote:
>>>
>>> I should mention -- for the most part I'm not an FPGA guy.  I'm circuit
>>> design and software, with enough FPGA chops to do simple stuff.  I have
>>> done FPGA projects that have left the customer happy, but I've done
>>> more work that involves credibly _threatening_ (one says "offering"
>>> with an ingratiating smile for maximum effect) to write some Verilog or
>>> VHDL. Given a reasonably competent and territorial FPGA guy, this
>>> usually prompts a response of "here, Tim, let me take that off your
>>> hands".
>>
>> I think it's more like the FPGA guy feels you are offensive to the art
>> of FPGAs.  Maybe not truly dangerous, but not the sort of thing an FPGA
>> guy wants to think about.  I haven't worked with you obviously, I'm just
>> going from your description.  :)
>
> You're probably right.  I believe that I have a pretty good grasp of
> what's possible with FPGAs, but I'm not an experienced or even a hugely
> interested practitioner.

I was a bit confused by your description of using HDL.  You do use HDL 
now, right?

-- 

Rick C

Article: 158917
Subject: Re: Multi-port memory
From: Tim Wescott <tim@seemywebsite.com>
Date: Mon, 23 May 2016 01:44:27 -0500
Links: << >>  << T >>  << A >>
On Sun, 22 May 2016 06:37:31 -0400, rickman wrote:

> On 5/22/2016 1:32 AM, Tim Wescott wrote:
>> On Sat, 21 May 2016 23:32:59 -0400, rickman wrote:
>>
>>> On 5/21/2016 1:43 PM, Tim Wescott wrote:
>>>>
>>>> I should mention -- for the most part I'm not an FPGA guy.  I'm
>>>> circuit design and software, with enough FPGA chops to do simple
>>>> stuff.  I have done FPGA projects that have left the customer happy,
>>>> but I've done more work that involves credibly _threatening_ (one
>>>> says "offering" with an ingratiating smile for maximum effect) to
>>>> write some Verilog or VHDL. Given a reasonably competent and
>>>> territorial FPGA guy, this usually prompts a response of "here, Tim,
>>>> let me take that off your hands".
>>>
>>> I think it's more like the FPGA guy feels you are offensive to the art
>>> of FPGAs.  Maybe not truly dangerous, but not the sort of thing an
>>> FPGA guy wants to think about.  I haven't worked with you obviously,
>>> I'm just going from your description.  :)
>>
>> You're probably right.  I believe that I have a pretty good grasp of
>> what's possible with FPGAs, but I'm not an experienced or even a hugely
>> interested practitioner.
> 
> I was a bit confused by your description of using HDL.  You do use HDL
> now, right?

Yes, although my favorite HDL is a block diagram and a bunch of math, 
handed to someone like you.  It works ever so much better for everyone on 
the project than me banging out Verilog or VHDL.

-- 
Tim Wescott
Control systems, embedded software and circuit design
I'm looking for work!  See my website if you're interested
http://www.wescottdesign.com

Article: 158918
Subject: Re: Multi-port memory
From: rickman <gnuarm@gmail.com>
Date: Mon, 23 May 2016 13:18:24 -0400
Links: << >>  << T >>  << A >>
On 5/23/2016 2:44 AM, Tim Wescott wrote:
> On Sun, 22 May 2016 06:37:31 -0400, rickman wrote:
>
>> On 5/22/2016 1:32 AM, Tim Wescott wrote:
>>> On Sat, 21 May 2016 23:32:59 -0400, rickman wrote:
>>>
>>>> On 5/21/2016 1:43 PM, Tim Wescott wrote:
>>>>>
>>>>> I should mention -- for the most part I'm not an FPGA guy.  I'm
>>>>> circuit design and software, with enough FPGA chops to do simple
>>>>> stuff.  I have done FPGA projects that have left the customer happy,
>>>>> but I've done more work that involves credibly _threatening_ (one
>>>>> says "offering" with an ingratiating smile for maximum effect) to
>>>>> write some Verilog or VHDL. Given a reasonably competent and
>>>>> territorial FPGA guy, this usually prompts a response of "here, Tim,
>>>>> let me take that off your hands".
>>>>
>>>> I think it's more like the FPGA guy feels you are offensive to the art
>>>> of FPGAs.  Maybe not truly dangerous, but not the sort of thing an
>>>> FPGA guy wants to think about.  I haven't worked with you obviously,
>>>> I'm just going from your description.  :)
>>>
>>> You're probably right.  I believe that I have a pretty good grasp of
>>> what's possible with FPGAs, but I'm not an experienced or even a hugely
>>> interested practitioner.
>>
>> I was a bit confused by your description of using HDL.  You do use HDL
>> now, right?
>
> Yes, although my favorite HDL is a block diagram and a bunch of math,
> handed to someone like you.  It works ever so much better for everyone on
> the project than me banging out Verilog or VHDL.

Yeah, see, that is the part where it gets dangerous.  Not trying to be 
rude, but when you "sort of" know how to do something, that is when 
mistakes get made.  HDL isn't so horribly hard, but there are subtleties 
that can cause hard to debug problems.  When you only do something once 
in a while and nothing very big, you never really learn all the details.

I don't consider myself proficient in Verilog because I have only worked 
with it a bit.  In particular there are a lot of assumptions the tools 
make when you do arithmetic that need to be understood to get the 
correct results.  I don't know them all and I've never found a good book 
on the subject, so I stick with VHDL where most everything is explicit 
with no assumptions.  Then VHDL can be cranky if you don't know how to 
work within the various restrictions.

You must not be so bad at HDL.  You've gotten along so far without major 
issues, right?

My main gripe with non-FPGA people is the frequent biases they seem to 
develop that FPGAs have to be power hungry, large and complex to work 
with.  I mostly work with small devices that use little power from a 
single power supply where the only complexity is in the design itself. 
Not too many people appreciate these types of devices.

As a demonstration I have wanted to design a battery powered WWVB 
receiver in an FPGA.  Will do it some day.

-- 

Rick C

Article: 158919
Subject: Re: Multi-port memory
From: Tim Wescott <seemywebsite@myfooter.really>
Date: Mon, 23 May 2016 13:02:01 -0500
Links: << >>  << T >>  << A >>
On Mon, 23 May 2016 13:18:24 -0400, rickman wrote:

> On 5/23/2016 2:44 AM, Tim Wescott wrote:
>> On Sun, 22 May 2016 06:37:31 -0400, rickman wrote:
>>
>>> On 5/22/2016 1:32 AM, Tim Wescott wrote:
>>>> On Sat, 21 May 2016 23:32:59 -0400, rickman wrote:
>>>>
>>>>> On 5/21/2016 1:43 PM, Tim Wescott wrote:
>>>>>>
>>>>>> I should mention -- for the most part I'm not an FPGA guy.  I'm
>>>>>> circuit design and software, with enough FPGA chops to do simple
>>>>>> stuff.  I have done FPGA projects that have left the customer
>>>>>> happy,
>>>>>> but I've done more work that involves credibly _threatening_ (one
>>>>>> says "offering" with an ingratiating smile for maximum effect) to
>>>>>> write some Verilog or VHDL. Given a reasonably competent and
>>>>>> territorial FPGA guy, this usually prompts a response of "here,
>>>>>> Tim,
>>>>>> let me take that off your hands".
>>>>>
>>>>> I think it's more like the FPGA guy feels you are offensive to the
>>>>> art of FPGAs.  Maybe not truly dangerous, but not the sort of thing
>>>>> an FPGA guy wants to think about.  I haven't worked with you
>>>>> obviously, I'm just going from your description.  :)
>>>>
>>>> You're probably right.  I believe that I have a pretty good grasp of
>>>> what's possible with FPGAs, but I'm not an experienced or even a
>>>> hugely interested practitioner.
>>>
>>> I was a bit confused by your description of using HDL.  You do use HDL
>>> now, right?
>>
>> Yes, although my favorite HDL is a block diagram and a bunch of math,
>> handed to someone like you.  It works ever so much better for everyone
>> on the project than me banging out Verilog or VHDL.
> 
> Yeah, see, that is the part where it gets dangerous.  Not trying to be
> rude, but when you "sort of" know how to do something, that is when
> mistakes get made.  HDL isn't so horribly hard, but there are subtleties
> that can cause hard to debug problems.  When you only do something once
> in a while and nothing very big, you never really learn all the details.

<snip>

Well, that's why I prefer to hand my system designs to an FPGA expert 
instead of trying to implement them myself.  In general, if a customer 
calls and wants FPGA work done I say "no" and explain why.  If money got 
tight and there was no other work available, and someone just HAD to have 
ME do the FPGA work, then I'd (A) warn them one last time that I'm just a 
hacker, and (B) deeply discount my time.

I think I've done FPGA work for money twice: once was for a friend who 
understood, and the work was deeply discounted; the other was for a 
customer who had FPGA people on staff, but those guys didn't have time to 
do the work when I did it.  In that case the first communication I got 
from the FPGA guy was "you're a software guy, aren't you?"

> My main gripe with non-FPGA people is the frequent biases they seem to
> develop that FPGAs have to be power hungry, large and complex to work
> with.  I mostly work with small devices that use little power from a
> single power supply where the only complexity is in the design itself.
> Not too many people appreciate these types of devices.
>
> As a demonstration I have wanted to design a battery powered WWVB
> receiver in an FPGA.  Will do it some day.

I want to see it!  Most of the work that I've done when there are FPGAs 
in the mix have been with processors doing the complicated slow stuff, 
and FPGAs doing the (relatively) simple fast stuff -- things like video 
processing, where the FPGA is fondling every pixel but the processor is 
managing managing the transfer of lines over a digital data link (and 
with a different digital link the processor would be further away than 
that).

For me, at least, I find that to do designs in an HDL I essentially have 
to think at the same level of detail that I do when writing code in 
assembly -- trying to get more abstract, at least for me, leads to lots 
of wasted gates and unexpectedly long propagation times.

-- 

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

I'm looking for work -- see my website!

Article: 158920
Subject: Re: Multi-port memory
From: rickman <gnuarm@gmail.com>
Date: Mon, 23 May 2016 15:00:29 -0400
Links: << >>  << T >>  << A >>
On 5/23/2016 2:02 PM, Tim Wescott wrote:
> On Mon, 23 May 2016 13:18:24 -0400, rickman wrote:
>
>> On 5/23/2016 2:44 AM, Tim Wescott wrote:
>>> On Sun, 22 May 2016 06:37:31 -0400, rickman wrote:
>>>
>>>> On 5/22/2016 1:32 AM, Tim Wescott wrote:
>>>>> On Sat, 21 May 2016 23:32:59 -0400, rickman wrote:
>>>>>
>>>>>> On 5/21/2016 1:43 PM, Tim Wescott wrote:
>>>>>>>
>>>>>>> I should mention -- for the most part I'm not an FPGA guy.  I'm
>>>>>>> circuit design and software, with enough FPGA chops to do simple
>>>>>>> stuff.  I have done FPGA projects that have left the customer
>>>>>>> happy,
>>>>>>> but I've done more work that involves credibly _threatening_ (one
>>>>>>> says "offering" with an ingratiating smile for maximum effect) to
>>>>>>> write some Verilog or VHDL. Given a reasonably competent and
>>>>>>> territorial FPGA guy, this usually prompts a response of "here,
>>>>>>> Tim,
>>>>>>> let me take that off your hands".
>>>>>>
>>>>>> I think it's more like the FPGA guy feels you are offensive to the
>>>>>> art of FPGAs.  Maybe not truly dangerous, but not the sort of thing
>>>>>> an FPGA guy wants to think about.  I haven't worked with you
>>>>>> obviously, I'm just going from your description.  :)
>>>>>
>>>>> You're probably right.  I believe that I have a pretty good grasp of
>>>>> what's possible with FPGAs, but I'm not an experienced or even a
>>>>> hugely interested practitioner.
>>>>
>>>> I was a bit confused by your description of using HDL.  You do use HDL
>>>> now, right?
>>>
>>> Yes, although my favorite HDL is a block diagram and a bunch of math,
>>> handed to someone like you.  It works ever so much better for everyone
>>> on the project than me banging out Verilog or VHDL.
>>
>> Yeah, see, that is the part where it gets dangerous.  Not trying to be
>> rude, but when you "sort of" know how to do something, that is when
>> mistakes get made.  HDL isn't so horribly hard, but there are subtleties
>> that can cause hard to debug problems.  When you only do something once
>> in a while and nothing very big, you never really learn all the details.
>
> <snip>
>
> Well, that's why I prefer to hand my system designs to an FPGA expert
> instead of trying to implement them myself.  In general, if a customer
> calls and wants FPGA work done I say "no" and explain why.  If money got
> tight and there was no other work available, and someone just HAD to have
> ME do the FPGA work, then I'd (A) warn them one last time that I'm just a
> hacker, and (B) deeply discount my time.

You could refer the work to someone you know.  If the work is bigger 
than just the FPGA work, you can sub it out to someone else.  I did that 
on a project that was just too large for me and it worked pretty well. 
I did have one part I had to take over.  I had worked with the guy one 
time and had not gained a full appreciation of the flake factor.  In the 
end it was just moonlighting work for him and he gave it last priority 
over even his personal life.  It worked out in the end.


> I think I've done FPGA work for money twice: once was for a friend who
> understood, and the work was deeply discounted; the other was for a
> customer who had FPGA people on staff, but those guys didn't have time to
> do the work when I did it.  In that case the first communication I got
> from the FPGA guy was "you're a software guy, aren't you?"

Lol.  It often shows, but being a software person doesn't automatically 
make someone a poor candidate for FPGA work.  They just have to be a bit 
flexible and forget a *lot* of what they know about software.  I guess 
it's hard to know what to forget and what to retain.  It helps if they 
have someone more experienced to oversee the work and to review the 
results.

In the other direction, I helped a friend who is a great hardware 
designer spin up on FPGA work.  I did one module and turned it over to 
him with some one-on-one time to get him familiar with what I did and he 
was off and running.


>> My main gripe with non-FPGA people is the frequent biases they seem to
>> develop that FPGAs have to be power hungry, large and complex to work
>> with.  I mostly work with small devices that use little power from a
>> single power supply where the only complexity is in the design itself.
>> Not too many people appreciate these types of devices.
>>
>> As a demonstration I have wanted to design a battery powered WWVB
>> receiver in an FPGA.  Will do it some day.
>
> I want to see it!  Most of the work that I've done when there are FPGAs
> in the mix have been with processors doing the complicated slow stuff,
> and FPGAs doing the (relatively) simple fast stuff -- things like video
> processing, where the FPGA is fondling every pixel but the processor is
> managing managing the transfer of lines over a digital data link (and
> with a different digital link the processor would be further away than
> that).

Depending on how fast you need, there are some low power iCE40 devices 
from Lattice, since they bought Silicon Blue.  Of course the power goes 
up with clock speed, but they start at nearly zero (100 uA) and go up 
linearly.  They aren't real big and don't have multipliers, so likely 
not for the above design.  The XP2 line has DSP blocks plus multipliers 
and would be lower power than many product lines, but not as low as the 
iCE40.


> For me, at least, I find that to do designs in an HDL I essentially have
> to think at the same level of detail that I do when writing code in
> assembly -- trying to get more abstract, at least for me, leads to lots
> of wasted gates and unexpectedly long propagation times.

It helps to think in terms of the functional blocks that are optimal for 
FPGAs.  Adders are good, but you can often avoid an extra adder by 
making sure the carry out can be used for a compare operation.  Any time 
you do an operation on a bus, consider how it would be implemented. 
Muxes eat up LUTs and can often be combined with an adder by zeroing an 
input.  It all depends on the design.  Sometimes the design just eats 
LUTs and there's nothing to be done other than minor optimizations.

The problems with HDL don't come from these sorts of issues though. 
They come from misusing the language.  Which do you work in, VHDL or 
Verilog?

-- 

Rick C

Article: 158921
Subject: Re: Multi-port memory
From: Tim Wescott <seemywebsite@myfooter.really>
Date: Tue, 24 May 2016 12:20:49 -0500
Links: << >>  << T >>  << A >>
On Mon, 23 May 2016 15:00:29 -0400, rickman wrote:

> On 5/23/2016 2:02 PM, Tim Wescott wrote:
>> On Mon, 23 May 2016 13:18:24 -0400, rickman wrote:
>>
>>> On 5/23/2016 2:44 AM, Tim Wescott wrote:
>>>> On Sun, 22 May 2016 06:37:31 -0400, rickman wrote:
>>>>
>>>>> On 5/22/2016 1:32 AM, Tim Wescott wrote:
>>>>>> On Sat, 21 May 2016 23:32:59 -0400, rickman wrote:
>>>>>>
>>>>>>> On 5/21/2016 1:43 PM, Tim Wescott wrote:
>>>>>>>>
>>>>>>>> I should mention -- for the most part I'm not an FPGA guy.  I'm
>>>>>>>> circuit design and software, with enough FPGA chops to do simple
>>>>>>>> stuff.  I have done FPGA projects that have left the customer
>>>>>>>> happy,
>>>>>>>> but I've done more work that involves credibly _threatening_ (one
>>>>>>>> says "offering" with an ingratiating smile for maximum effect) to
>>>>>>>> write some Verilog or VHDL. Given a reasonably competent and
>>>>>>>> territorial FPGA guy, this usually prompts a response of "here,
>>>>>>>> Tim,
>>>>>>>> let me take that off your hands".
>>>>>>>
>>>>>>> I think it's more like the FPGA guy feels you are offensive to the
>>>>>>> art of FPGAs.  Maybe not truly dangerous, but not the sort of
>>>>>>> thing an FPGA guy wants to think about.  I haven't worked with you
>>>>>>> obviously, I'm just going from your description.  :)
>>>>>>
>>>>>> You're probably right.  I believe that I have a pretty good grasp
>>>>>> of what's possible with FPGAs, but I'm not an experienced or even a
>>>>>> hugely interested practitioner.
>>>>>
>>>>> I was a bit confused by your description of using HDL.  You do use
>>>>> HDL now, right?
>>>>
>>>> Yes, although my favorite HDL is a block diagram and a bunch of math,
>>>> handed to someone like you.  It works ever so much better for
>>>> everyone on the project than me banging out Verilog or VHDL.
>>>
>>> Yeah, see, that is the part where it gets dangerous.  Not trying to be
>>> rude, but when you "sort of" know how to do something, that is when
>>> mistakes get made.  HDL isn't so horribly hard, but there are
>>> subtleties that can cause hard to debug problems.  When you only do
>>> something once in a while and nothing very big, you never really learn
>>> all the details.
>>
>> <snip>
>>
>> Well, that's why I prefer to hand my system designs to an FPGA expert
>> instead of trying to implement them myself.  In general, if a customer
>> calls and wants FPGA work done I say "no" and explain why.  If money
>> got tight and there was no other work available, and someone just HAD
>> to have ME do the FPGA work, then I'd (A) warn them one last time that
>> I'm just a hacker, and (B) deeply discount my time.
> 
> You could refer the work to someone you know.  If the work is bigger
> than just the FPGA work, you can sub it out to someone else.  I did that
> on a project that was just too large for me and it worked pretty well. I
> did have one part I had to take over.  I had worked with the guy one
> time and had not gained a full appreciation of the flake factor.  In the
> end it was just moonlighting work for him and he gave it last priority
> over even his personal life.  It worked out in the end.
> 
> 
>> I think I've done FPGA work for money twice: once was for a friend who
>> understood, and the work was deeply discounted; the other was for a
>> customer who had FPGA people on staff, but those guys didn't have time
>> to do the work when I did it.  In that case the first communication I
>> got from the FPGA guy was "you're a software guy, aren't you?"
> 
> Lol.  It often shows, but being a software person doesn't automatically
> make someone a poor candidate for FPGA work.  They just have to be a bit
> flexible and forget a *lot* of what they know about software.  I guess
> it's hard to know what to forget and what to retain.  It helps if they
> have someone more experienced to oversee the work and to review the
> results.
> 
> In the other direction, I helped a friend who is a great hardware
> designer spin up on FPGA work.  I did one module and turned it over to
> him with some one-on-one time to get him familiar with what I did and he
> was off and running.
> 
> 
>>> My main gripe with non-FPGA people is the frequent biases they seem to
>>> develop that FPGAs have to be power hungry, large and complex to work
>>> with.  I mostly work with small devices that use little power from a
>>> single power supply where the only complexity is in the design itself.
>>> Not too many people appreciate these types of devices.
>>>
>>> As a demonstration I have wanted to design a battery powered WWVB
>>> receiver in an FPGA.  Will do it some day.
>>
>> I want to see it!  Most of the work that I've done when there are FPGAs
>> in the mix have been with processors doing the complicated slow stuff,
>> and FPGAs doing the (relatively) simple fast stuff -- things like video
>> processing, where the FPGA is fondling every pixel but the processor is
>> managing managing the transfer of lines over a digital data link (and
>> with a different digital link the processor would be further away than
>> that).
> 
> Depending on how fast you need, there are some low power iCE40 devices
> from Lattice, since they bought Silicon Blue.  Of course the power goes
> up with clock speed, but they start at nearly zero (100 uA) and go up
> linearly.  They aren't real big and don't have multipliers, so likely
> not for the above design.  The XP2 line has DSP blocks plus multipliers
> and would be lower power than many product lines, but not as low as the
> iCE40.
> 
> 
>> For me, at least, I find that to do designs in an HDL I essentially
>> have to think at the same level of detail that I do when writing code
>> in assembly -- trying to get more abstract, at least for me, leads to
>> lots of wasted gates and unexpectedly long propagation times.
> 
> It helps to think in terms of the functional blocks that are optimal for
> FPGAs.  Adders are good, but you can often avoid an extra adder by
> making sure the carry out can be used for a compare operation.  Any time
> you do an operation on a bus, consider how it would be implemented.
> Muxes eat up LUTs and can often be combined with an adder by zeroing an
> input.  It all depends on the design.  Sometimes the design just eats
> LUTs and there's nothing to be done other than minor optimizations.
> 
> The problems with HDL don't come from these sorts of issues though. They
> come from misusing the language.  Which do you work in, VHDL or Verilog?

I am equally inept in either one.  Really, I think that at my level it 
has less to do with the language and more to do with not having an 
intuitive grasp of what's going to fit well with a given FPGA structure 
vs. what's not, and if I'm not careful I start to think sequentially, 
which translates to long if-then-else chains in either language, which 
get synthesized as these really wide-to-one MUX's with high delays in the 
chip.

-- 

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

I'm looking for work -- see my website!

Article: 158922
Subject: Re: Multi-port memory
From: rickman <gnuarm@gmail.com>
Date: Tue, 24 May 2016 19:17:51 -0400
Links: << >>  << T >>  << A >>
On 5/24/2016 1:20 PM, Tim Wescott wrote:
>
> I am equally inept in either one.  Really, I think that at my level it
> has less to do with the language and more to do with not having an
> intuitive grasp of what's going to fit well with a given FPGA structure
> vs. what's not, and if I'm not careful I start to think sequentially,
> which translates to long if-then-else chains in either language, which
> get synthesized as these really wide-to-one MUX's with high delays in the
> chip.

Yeah, I know what you mean.  The one guy I know who was able to complete 
a design without going over to the "dark" side (thinking hardware) 
needed to do a not too complex project in a very large FPGA.  So he 
didn't care about size but needed to get it done quickly.  I gave him 
some help off the group, but not a lot and he was able to get the job 
done.  He was appreciative since we had talked about my coming to town 
to help formally, but management turned it down.  He ended up showing 
his appreciation by getting them to send me a check for my troubles, 
which was not necessary at all.  It was only a few hours which I chalked 
up to good will.  So I sent him a polo shirt with my company logo, lol.

If you would like any assistance or review of code, I'd be happy to help 
on the books or if it isn't too many hours, off the books.  I'm having 
my hip done in two weeks, so I'll have plenty of time recouping when I'm 
bored and looking for something to do.  Likely I won't really find much 
truly wrong with your code, but maybe I'll have suggestions on 
techniques that might make it simpler.

The funny part is I can do this stuff easily, but I would have a very 
hard time writing it down.  I just put together a brief presentation to 
go with a presentation Dr. Ting is doing for the Sunnyvale Forth Users 
Group (SVFIG) on a VHDL 8080 design.  His example code is an 8080, 
memory and a UART.  He verifies it runs by running Forth on it and 
getting an OK> prompt.  So I wrote a testbench that reads commands from 
a text file to instruct it to write data on the data bus and verify the 
addresses and returned data.  With just an 11 line test program I found 
a flaw in the increment/decrement instructions.  I guess I got lucky.

I prepared some slides^H^H^H^H^H^H uh, a power point presentation, but I 
don't know it is so good.  I should stick to writing code I think.

-- 

Rick C

Article: 158923
Subject: VHDL BFMs and VVCs for AXI4-Lite, Avalon-MM, UART, I2C and SPI - for
From: Espen Tallaksen <espen.tallaksen@bitvis.no>
Date: Wed, 25 May 2016 05:16:03 -0700 (PDT)
Links: << >>  << T >>  << A >>
UVVM - the new VHDL verification methodology is a very good way to structur=
e your VHDL testbenches - and to make easily understandable, maintainable, =
extendible and reusable testbench architectures.

UVVM is free and open source, and now a whole set of BFMs and Verification =
Components are also available - open source and for free. This allows a ver=
y fast kick-off for new users of UVVM, and of course a really good start fo=
r any VHDL testbench development. They also serve as examples on how users =
can make their own BFMs and VVCs. In fact - if you have already made your B=
FM procedures for your proprietary protocol - you can make a VVC for that i=
nterface in 15 to 60 minutes.

Spend 5 minutes to read our post
'Advanced VHDL Verification - Made simple - For anyone'
https://www.linkedin.com/pulse/advanced-vhdl-verification-made-simple-anyon=
e-espen-tallaksen?trk=3Dmp-author-card, and see for your self how UVVM will=
 allow far better and more structured testbenches to be implemented far fas=
ter than before.
(Includes picture, so can't be posted here)

UVVM is free and open source, and you can use it for anything you like, wit=
h no restrictions other than the standard MIT open source license.
UVVM is available from github.com  and  bitvis.no (released in February 201=
6).=20

Note that advanced randomization and coverage is available with UVVM via th=
e included OSVVM or adapted UVVM-OSVVM.

Available BFMs and VVCs (VHDL Verification Components) are:
- AXI4-Lite
- Avalon-MM (Single access so far)
- SBI: Simple Bus Interface (Single cycle, optional ready - very simple bus=
 interface)
- UART
- I2C
- SPI (coming in June)
- GPIO (coming in June)

As UVVM takes off we expect the VHDL community will make more BFMs and VVCs=
 available.

Article: 158924
Subject: Re: Multi-port memory
From: Tim Wescott <tim@seemywebsite.com>
Date: Wed, 25 May 2016 11:59:14 -0500
Links: << >>  << T >>  << A >>
On Tue, 24 May 2016 19:17:51 -0400, rickman wrote:

> On 5/24/2016 1:20 PM, Tim Wescott wrote:
>>
>> I am equally inept in either one.  Really, I think that at my level it
>> has less to do with the language and more to do with not having an
>> intuitive grasp of what's going to fit well with a given FPGA structure
>> vs. what's not, and if I'm not careful I start to think sequentially,
>> which translates to long if-then-else chains in either language, which
>> get synthesized as these really wide-to-one MUX's with high delays in
>> the chip.
> 
> Yeah, I know what you mean.  The one guy I know who was able to complete
> a design without going over to the "dark" side (thinking hardware)
> needed to do a not too complex project in a very large FPGA.  So he
> didn't care about size but needed to get it done quickly.  I gave him
> some help off the group, but not a lot and he was able to get the job
> done.  He was appreciative since we had talked about my coming to town
> to help formally, but management turned it down.  He ended up showing
> his appreciation by getting them to send me a check for my troubles,
> which was not necessary at all.  It was only a few hours which I chalked
> up to good will.  So I sent him a polo shirt with my company logo, lol.
> 
> If you would like any assistance or review of code, I'd be happy to help
> on the books or if it isn't too many hours, off the books.  I'm having
> my hip done in two weeks, so I'll have plenty of time recouping when I'm
> bored and looking for something to do.  Likely I won't really find much
> truly wrong with your code, but maybe I'll have suggestions on
> techniques that might make it simpler.
> 
> The funny part is I can do this stuff easily, but I would have a very
> hard time writing it down.  I just put together a brief presentation to
> go with a presentation Dr. Ting is doing for the Sunnyvale Forth Users
> Group (SVFIG) on a VHDL 8080 design.  His example code is an 8080,
> memory and a UART.  He verifies it runs by running Forth on it and
> getting an OK> prompt.  So I wrote a testbench that reads commands from
> a text file to instruct it to write data on the data bus and verify the
> addresses and returned data.  With just an 11 line test program I found
> a flaw in the increment/decrement instructions.  I guess I got lucky.
> 
> I prepared some slides^H^H^H^H^H^H uh, a power point presentation, but I
> don't know it is so good.  I should stick to writing code I think.

When I started I had hopes of founding a vast design engineering bureau, 
but it turns out that my sales & marketing chops simply aren't up to it.  
So it's just me.

Should a project cross my desk that requires combined FPGA & software 
work I'll give you a call -- should one cross my desk that requires 
_just_ FPGA work, I may well just give the prospect your name.

-- 
Tim Wescott
Control systems, embedded software and circuit design
I'm looking for work!  See my website if you're interested
http://www.wescottdesign.com



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