Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
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) -- JecelArticle: 158901
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 CArticle: 158902
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: 158903On 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, BobHArticle: 158904
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. BobHArticle: 158905
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 CArticle: 158906
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! BobHArticle: 158907
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, WojtekArticle: 158908
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.comArticle: 158909
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
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 CArticle: 158911
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.comArticle: 158912
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.comArticle: 158913
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
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 CArticle: 158915
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.comArticle: 158916
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 CArticle: 158917
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.comArticle: 158918
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 CArticle: 158919
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
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 CArticle: 158921
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
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 CArticle: 158923
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
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:
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