Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
On a sunny day (Fri, 22 Nov 2013 08:57:12 -0800) it happened John Larkin <jjlarkin@highNOTlandTHIStechnologyPART.com> wrote in <jj2v8997iq6amci40mr1t2g5l2e040ojgu@4ax.com>: >We're into this signal processing project, using a microZed/ZYNQ thing as the >compute engine. > >After a week or so of work by an FPGA guy and a programmer, we can now actually >read and write an FPGA register from a C program, and wiggle a bit on a >connector pin. Amazingly, the uZed eval kit does not include a demo of this, and >the default boot image does not configure the FPGA! > >We're using their build tools to embed the FPGA config into the boot image. We'd >really like to be able to have a C program read a bitstream file and reconfigure >the FPGA, but we haven't been able to figure that out. > >If we run a C program that wiggles a pin as fast as it can, we can do a write to >the FPGA register about every 170 ns. Without any attempts at optimization (like >dedicating the second ARM core to the loop) we see stutters (OS stealing our >CPU) that last tens or hundreds of microseconds, occasionally a full >millisecond. That might get worse if we run TCP/IP sessions or host web pages or >something, so dedicating the second ARM to realtime stuff would be good. In my view FPGA should be used for - or used as hardware solution. Putting a processor in a FPGA will work. and a multitasker will constantly see I?O interruped. use the procssor for what the processor is good for, and do the rest in hardware. If you want I/O speed... Or any speed. Else you are just building an other _slow_ mobo. and then may as well use this: http://www.bugblat.com/products/pif/ Without any defined spec for the application who knows? Ad Jim says: You are about as vague as it gets on that,Article: 156076
On Fri, 22 Nov 2013 08:57:12 -0800, John Larkin wrote: > We're into this signal processing project, using a microZed/ZYNQ thing > as the compute engine. > > After a week or so of work by an FPGA guy and a programmer, we can now > actually read and write an FPGA register from a C program, and wiggle a > bit on a connector pin. Amazingly, the uZed eval kit does not include a > demo of this, and the default boot image does not configure the FPGA! > > We're using their build tools to embed the FPGA config into the boot > image. We'd really like to be able to have a C program read a bitstream > file and reconfigure the FPGA, but we haven't been able to figure that > out. > > If we run a C program that wiggles a pin as fast as it can, we can do a > write to the FPGA register about every 170 ns. Without any attempts at > optimization (like dedicating the second ARM core to the loop) we see > stutters (OS stealing our CPU) that last tens or hundreds of > microseconds, occasionally a full millisecond. That might get worse if > we run TCP/IP sessions or host web pages or something, so dedicating the > second ARM to realtime stuff would be good. There's not nearly enough information there, but if you're serious about real time you don't just throw a bag of unknown software at something and expect it to work. Operating systems don't steal CPU time -- programmers steal CPU time, sometimes by choosing the wrong OS. -- Tim Wescott Wescott Design Services http://www.wescottdesign.comArticle: 156077
On 11/22/2013 11:57 AM, John Larkin wrote: > > > We're into this signal processing project, using a microZed/ZYNQ thing as the > compute engine. > > After a week or so of work by an FPGA guy and a programmer, we can now actually > read and write an FPGA register from a C program, and wiggle a bit on a > connector pin. Amazingly, the uZed eval kit does not include a demo of this, and > the default boot image does not configure the FPGA! > > We're using their build tools to embed the FPGA config into the boot image. We'd > really like to be able to have a C program read a bitstream file and reconfigure > the FPGA, but we haven't been able to figure that out. > > If we run a C program that wiggles a pin as fast as it can, we can do a write to > the FPGA register about every 170 ns. Without any attempts at optimization (like > dedicating the second ARM core to the loop) we see stutters (OS stealing our > CPU) that last tens or hundreds of microseconds, occasionally a full > millisecond. That might get worse if we run TCP/IP sessions or host web pages or > something, so dedicating the second ARM to realtime stuff would be good. > > That is amazing, especially since so many manufacturers (*cough*ST*cough*) respond to any query by saying "Hack up the sample code." Cheers Phil Hobbs -- Dr Philip C D Hobbs Principal Consultant ElectroOptical Innovations LLC Optics, Electro-optics, Photonics, Analog Electronics 160 North State Road #203 Briarcliff Manor NY 10510 hobbs at electrooptical dot net http://electrooptical.netArticle: 156078
On Fri, 22 Nov 2013 08:57:12 -0800, John Larkin <jjlarkin@highNOTlandTHIStechnologyPART.com> wrote: > > >We're into this signal processing project, using a microZed/ZYNQ thing as the >compute engine. > >After a week or so of work by an FPGA guy and a programmer, we can now actually >read and write an FPGA register from a C program, and wiggle a bit on a >connector pin. Amazingly, the uZed eval kit does not include a demo of this, and >the default boot image does not configure the FPGA! > >We're using their build tools to embed the FPGA config into the boot image. We'd >really like to be able to have a C program read a bitstream file and reconfigure >the FPGA, but we haven't been able to figure that out. > >If we run a C program that wiggles a pin as fast as it can, we can do a write to >the FPGA register about every 170 ns. Without any attempts at optimization (like >dedicating the second ARM core to the loop) we see stutters (OS stealing our >CPU) that last tens or hundreds of microseconds, occasionally a full >millisecond. That might get worse if we run TCP/IP sessions or host web pages or >something, so dedicating the second ARM to realtime stuff would be good. Hi, John:- What OS is it running? Can you set the granularity of the task switching to something reasonable like low double-digit microseconds? This is a very interesting chip, especially with a bit bigger FPGA than the 7010.Article: 156079
That's very useful information since I'm seriously considering using a
MicroZed (or a Zybo - both have advantages and disadvantages for me).
Please continue to update us on your progress, and maybe write a
blog pointing us to how you overcome "issues" similar to the ones
you mention below.
On 22/11/13 16:57, John Larkin wrote:
> We're into this signal processing project, using a microZed/ZYNQ thing as the
> compute engine.
>
> After a week or so of work by an FPGA guy and a programmer, we can now actually
> read and write an FPGA register from a C program, and wiggle a bit on a
> connector pin. Amazingly, the uZed eval kit does not include a demo of this, and
> the default boot image does not configure the FPGA!
>
> We're using their build tools to embed the FPGA config into the boot image. We'd
> really like to be able to have a C program read a bitstream file and reconfigure
> the FPGA, but we haven't been able to figure that out.
Have you asked on any of the ZedBoard/MicroZed forums?
> If we run a C program that wiggles a pin as fast as it can, we can do a write to
> the FPGA register about every 170 ns.
That's a useful figure to have in mind.
> Without any attempts at optimization (like
> dedicating the second ARM core to the loop) we see stutters (OS stealing our
> CPU) that last tens or hundreds of microseconds, occasionally a full
> millisecond. That might get worse if we run TCP/IP sessions or host web pages or
> something, so dedicating the second ARM to realtime stuff would be good.
Personally I'm surprised that it is only a millisecond,
but then I'm a pessimist :)
I'm sure I'm teaching you to suck eggs, but you may
like to consider these points:
- contention at the hardware level, particularly w.r.t.
DRAM shared between two cores and the any FPGA logic
- cache effects. Even a 486 with its minimal cache
showed interrupt latencies that were sometimes
ten times the typical latency, all due to pessimal
caching. Larger caches would probably exhibit
poorer worst-case performance
- hard realtime systems are often best designed by
determining the worst-case software main-loop time
then once per main-loop configuring the hardware,
and then letting the hardware deal with all
actions for the next main-loop
For serious HRT work, personally I'd consider the XMOS
processors -- no caches nor interrupts so the dev system
can specifies the worst case performance. I don't know
about the propellor chips.
Article: 156080
On 22/11/13 17:35, Jan Panteltje wrote:
> On a sunny day (Fri, 22 Nov 2013 08:57:12 -0800) it happened John Larkin
> <jjlarkin@highNOTlandTHIStechnologyPART.com> wrote in
> <jj2v8997iq6amci40mr1t2g5l2e040ojgu@4ax.com>:
>
>> We're into this signal processing project, using a microZed/ZYNQ thing as the
>> compute engine.
>>
>> After a week or so of work by an FPGA guy and a programmer, we can now actually
>> read and write an FPGA register from a C program, and wiggle a bit on a
>> connector pin. Amazingly, the uZed eval kit does not include a demo of this, and
>> the default boot image does not configure the FPGA!
>>
>> We're using their build tools to embed the FPGA config into the boot image. We'd
>> really like to be able to have a C program read a bitstream file and reconfigure
>> the FPGA, but we haven't been able to figure that out.
>>
>> If we run a C program that wiggles a pin as fast as it can, we can do a write to
>> the FPGA register about every 170 ns. Without any attempts at optimization (like
>> dedicating the second ARM core to the loop) we see stutters (OS stealing our
>> CPU) that last tens or hundreds of microseconds, occasionally a full
>> millisecond. That might get worse if we run TCP/IP sessions or host web pages or
>> something, so dedicating the second ARM to realtime stuff would be good.
>
> In my view FPGA should be used for - or used as hardware solution.
I don't think there's any argument about that.
But it isn't the only consideration and doesn't invalidate the
concepts behind the Zynq chips.
> Putting a processor in a FPGA will work. and a multitasker will constantly see I?O interruped.
> use the procssor for what the processor is good for, and do the rest in hardware.
> If you want I/O speed... Or any speed.
I/O speed is only one aspect. In most cases:
- predictable worst-case latency is a more significant parameter
- precision relative timing is a more significant parameter
- any processor with a cache /will/ cause problems w.r.t.
worst-case software guarantees
> Else you are just building an other _slow_ mobo.
> and then may as well use this:
> http://www.bugblat.com/products/pif/
If you know of any boards that can be added to an RPi or something
similar and contains an FPGA that can capture three digital inputs
at >=1 GSa/s each, please let me know.
> Without any defined spec for the application who knows?
> Ad Jim says: You are about as vague as it gets on that,
Sure, but the poster didn't want advice about his application!
Article: 156081On 22/11/13 17:35, Jan Panteltje wrote: > Else you are just building an other _slow_ mobo. > and then may as well use this: > http://www.bugblat.com/products/pif/ What's the peak rate at which the RPi could read data from the FPGA and copy it to DRAM? I haven't had rime to understand the RPI's i/o, yet. My concern is that while there are several i/o bits available on the GPIO connector, they can't all be read simultaneously. If true then GPIO i/o would be reduced to the level of a bit-banged interface!Article: 156082
On Fri, 22 Nov 2013 17:35:52 GMT, Jan Panteltje <pNaonStpealmtje@yahoo.com> wrote: >On a sunny day (Fri, 22 Nov 2013 08:57:12 -0800) it happened John Larkin ><jjlarkin@highNOTlandTHIStechnologyPART.com> wrote in ><jj2v8997iq6amci40mr1t2g5l2e040ojgu@4ax.com>: > >>We're into this signal processing project, using a microZed/ZYNQ thing as the >>compute engine. >> >>After a week or so of work by an FPGA guy and a programmer, we can now actually >>read and write an FPGA register from a C program, and wiggle a bit on a >>connector pin. Amazingly, the uZed eval kit does not include a demo of this, and >>the default boot image does not configure the FPGA! >> >>We're using their build tools to embed the FPGA config into the boot image. We'd >>really like to be able to have a C program read a bitstream file and reconfigure >>the FPGA, but we haven't been able to figure that out. >> >>If we run a C program that wiggles a pin as fast as it can, we can do a write to >>the FPGA register about every 170 ns. Without any attempts at optimization (like >>dedicating the second ARM core to the loop) we see stutters (OS stealing our >>CPU) that last tens or hundreds of microseconds, occasionally a full >>millisecond. That might get worse if we run TCP/IP sessions or host web pages or >>something, so dedicating the second ARM to realtime stuff would be good. > >In my view FPGA should be used for - or used as hardware solution. >Putting a processor in a FPGA will work. and a multitasker will constantly see I?O interruped. >use the procssor for what the processor is good for, and do the rest in hardware. >If you want I/O speed... Or any speed. >Else you are just building an other _slow_ mobo. >and then may as well use this: > http://www.bugblat.com/products/pif/ > >Without any defined spec for the application who knows? There is a perfectly good, detailed spec. You can't see it. >Ad Jim says: You are about as vague as it gets on that, I'm building a box that accepts an analog input, crunches it in complex ways, and makes an analog output. ZED is an ideal platform. All that nasty DRAM and flash and power supply stuff is done, and it boots Linux out of the box. Having the dual-core ARM and the FPGA on the same chip is cool, because it avoids a lot of interconnect between two chips on a board. Unfortunately, ARM-FPGA transactions still cross a clock boundary, so aren't blindingly fast. -- John Larkin Highland Technology, Inc jlarkin at highlandtechnology dot com http://www.highlandtechnology.com Precision electronic instrumentation Picosecond-resolution Digital Delay and Pulse generators Custom laser drivers and controllers Photonics and fiberoptic TTL data links VME thermocouple, LVDT, synchro acquisition and simulationArticle: 156083
On Fri, 22 Nov 2013 13:33:14 -0500, Spehro Pefhany wrote: > On Fri, 22 Nov 2013 08:57:12 -0800, John Larkin > <jjlarkin@highNOTlandTHIStechnologyPART.com> wrote: > > >> >>We're into this signal processing project, using a microZed/ZYNQ thing >>as the compute engine. >> >>After a week or so of work by an FPGA guy and a programmer, we can now >>actually read and write an FPGA register from a C program, and wiggle a >>bit on a connector pin. Amazingly, the uZed eval kit does not include a >>demo of this, and the default boot image does not configure the FPGA! >> >>We're using their build tools to embed the FPGA config into the boot >>image. We'd really like to be able to have a C program read a bitstream >>file and reconfigure the FPGA, but we haven't been able to figure that >>out. >> >>If we run a C program that wiggles a pin as fast as it can, we can do a >>write to the FPGA register about every 170 ns. Without any attempts at >>optimization (like dedicating the second ARM core to the loop) we see >>stutters (OS stealing our CPU) that last tens or hundreds of >>microseconds, occasionally a full millisecond. That might get worse if >>we run TCP/IP sessions or host web pages or something, so dedicating the >>second ARM to realtime stuff would be good. > > Hi, John:- > > What OS is it running? Can you set the granularity of the task switching > to something reasonable like low double-digit microseconds? What programming model are you assuming? The RTOS's that I'm used to using make it very easy to make RTOS tasks event-driven off of interrupts, so the critical timing parameter for the OS is how rapidly it can reschedule a task after such an interrupt. Note that for every RTOS I've ever worked with, a programmer can cut the RTOS off at the knees by turning off interrupts and doing some lengthly process, or by doing lengthly processing in an ISR on a processor that automatically turns off interrupts on interrupt. No interrupts means the RTOS has no way of getting its hands on the processor. This "interrupt off" time can be essential if you have something that absolutely, positively must be done without interrupts, and it can be a valuable way to make an operation atomic if it happens to create less latency than using the OS's mutex scheme. But in the hands of a lazy programmer, it can absolutely kill real-time capability (as, for that matter, can misuse of mutexes or any number of other OS features). -- Tim Wescott Wescott Design Services http://www.wescottdesign.comArticle: 156084
On Fri, 22 Nov 2013 18:36:59 +0000, Tom Gardner wrote: > That's very useful information since I'm seriously considering using a > MicroZed (or a Zybo - both have advantages and disadvantages for me). > > Please continue to update us on your progress, and maybe write a blog > pointing us to how you overcome "issues" similar to the ones you mention > below. > > > On 22/11/13 16:57, John Larkin wrote: >> We're into this signal processing project, using a microZed/ZYNQ thing >> as the compute engine. >> >> After a week or so of work by an FPGA guy and a programmer, we can now >> actually read and write an FPGA register from a C program, and wiggle a >> bit on a connector pin. Amazingly, the uZed eval kit does not include a >> demo of this, and the default boot image does not configure the FPGA! >> >> We're using their build tools to embed the FPGA config into the boot >> image. We'd really like to be able to have a C program read a bitstream >> file and reconfigure the FPGA, but we haven't been able to figure that >> out. > > Have you asked on any of the ZedBoard/MicroZed forums? > > >> If we run a C program that wiggles a pin as fast as it can, we can do a >> write to the FPGA register about every 170 ns. > > That's a useful figure to have in mind. > > >> Without any attempts at optimization (like dedicating the second ARM >> core to the loop) we see stutters (OS stealing our CPU) that last tens >> or hundreds of microseconds, occasionally a full millisecond. That >> might get worse if we run TCP/IP sessions or host web pages or >> something, so dedicating the second ARM to realtime stuff would be >> good. > > Personally I'm surprised that it is only a millisecond, > but then I'm a pessimist :) > > I'm sure I'm teaching you to suck eggs, but you may like to consider > these points: > - contention at the hardware level, particularly w.r.t. > DRAM shared between two cores and the any FPGA logic > > - cache effects. Even a 486 with its minimal cache > showed interrupt latencies that were sometimes ten times the > typical latency, all due to pessimal caching. Larger caches would > probably exhibit poorer worst-case performance > > - hard realtime systems are often best designed by > determining the worst-case software main-loop time then once per > main-loop configuring the hardware, and then letting the hardware > deal with all actions for the next main-loop > > For serious HRT work, personally I'd consider the XMOS processors -- no > caches nor interrupts so the dev system can specifies the worst case > performance. I don't know about the propellor chips. Probably more egg sucking instruction, but if the instruction cache is big enough and allows it, you can lock down the lines that contain the critical ISRs and OS bits. You can only take this so far: at some point you need to either throw your hands up in despair, or find a way to fork that job into the FPGA. At the price of making your software inscrutable, and slowing down everything else, etc., etc., etc. -- Tim Wescott Wescott Design Services http://www.wescottdesign.comArticle: 156085
On Fri, 22 Nov 2013 13:33:14 -0500, Spehro Pefhany <speffSNIP@interlogDOTyou.knowwhat> wrote: >On Fri, 22 Nov 2013 08:57:12 -0800, John Larkin ><jjlarkin@highNOTlandTHIStechnologyPART.com> wrote: > >> >> >>We're into this signal processing project, using a microZed/ZYNQ thing as the >>compute engine. >> >>After a week or so of work by an FPGA guy and a programmer, we can now actually >>read and write an FPGA register from a C program, and wiggle a bit on a >>connector pin. Amazingly, the uZed eval kit does not include a demo of this, and >>the default boot image does not configure the FPGA! >> >>We're using their build tools to embed the FPGA config into the boot image. We'd >>really like to be able to have a C program read a bitstream file and reconfigure >>the FPGA, but we haven't been able to figure that out. >> >>If we run a C program that wiggles a pin as fast as it can, we can do a write to >>the FPGA register about every 170 ns. Without any attempts at optimization (like >>dedicating the second ARM core to the loop) we see stutters (OS stealing our >>CPU) that last tens or hundreds of microseconds, occasionally a full >>millisecond. That might get worse if we run TCP/IP sessions or host web pages or >>something, so dedicating the second ARM to realtime stuff would be good. > >Hi, John:- > >What OS is it running? Can you set the granularity of the task >switching to something reasonable like low double-digit microseconds? > >This is a very interesting chip, especially with a bit bigger FPGA >than the 7010. We're running the Linux that comes installed on the uZed. There's probably some way to make Linux run the realtime app on the second ARM core. I guess we could even force that to run bare-metal code if we had to. The current application will probably run fine if we do nothing special. We'll have some FIFOs in the FPGA to buffer stuff, so the occasional millisecond or so timeout won't break anything. I have been pressured for some time now to run C apps inside an FPGA, in a soft core processor, microBlaze or whatever. That never made sense to me, eating all those FPGA resources to get a pokey CPU with a tiny memory space. The new FPGA chips with hard ARM cores, cache, ram, and DRAM controllers mean it's time to do it. -- John Larkin Highland Technology, Inc jlarkin at highlandtechnology dot com http://www.highlandtechnology.com Precision electronic instrumentation Picosecond-resolution Digital Delay and Pulse generators Custom laser drivers and controllers Photonics and fiberoptic TTL data links VME thermocouple, LVDT, synchro acquisition and simulationArticle: 156086
On Fri, 22 Nov 2013 12:20:21 -0600, Tim Wescott <tim@seemywebsite.really> wrote: >On Fri, 22 Nov 2013 08:57:12 -0800, John Larkin wrote: > >> We're into this signal processing project, using a microZed/ZYNQ thing >> as the compute engine. >> >> After a week or so of work by an FPGA guy and a programmer, we can now >> actually read and write an FPGA register from a C program, and wiggle a >> bit on a connector pin. Amazingly, the uZed eval kit does not include a >> demo of this, and the default boot image does not configure the FPGA! >> >> We're using their build tools to embed the FPGA config into the boot >> image. We'd really like to be able to have a C program read a bitstream >> file and reconfigure the FPGA, but we haven't been able to figure that >> out. >> >> If we run a C program that wiggles a pin as fast as it can, we can do a >> write to the FPGA register about every 170 ns. Without any attempts at >> optimization (like dedicating the second ARM core to the loop) we see >> stutters (OS stealing our CPU) that last tens or hundreds of >> microseconds, occasionally a full millisecond. That might get worse if >> we run TCP/IP sessions or host web pages or something, so dedicating the >> second ARM to realtime stuff would be good. > >There's not nearly enough information there, but if you're serious about >real time you don't just throw a bag of unknown software at something and >expect it to work. Operating systems don't steal CPU time -- programmers >steal CPU time, sometimes by choosing the wrong OS. It's looking that the Linux that comes with the uZed will work fine for the current application. Is Linux "a bag of unknown software"? We need to do TCP/IP stuff, and manage waveform data files, run BIST, things like that, and using Linux sure makes that part easy. A lot of the functionality could be in ARM code or might be in the FPGA, but I'm moving as much as possible into the ARM. C is a lot easier to code and compile than VHDL. -- John Larkin Highland Technology, Inc jlarkin at highlandtechnology dot com http://www.highlandtechnology.com Precision electronic instrumentation Picosecond-resolution Digital Delay and Pulse generators Custom laser drivers and controllers Photonics and fiberoptic TTL data links VME thermocouple, LVDT, synchro acquisition and simulationArticle: 156087
On 22/11/13 19:10, Tim Wescott wrote: > On Fri, 22 Nov 2013 18:36:59 +0000, Tom Gardner wrote: >> For serious HRT work, personally I'd consider the XMOS processors -- no >> caches nor interrupts so the dev system can specifies the worst case >> performance. I don't know about the propellor chips. > > Probably more egg sucking instruction, but if the instruction cache is > big enough and allows it, you can lock down the lines that contain the > critical ISRs and OS bits. I know the i960 allowed you to do that. Which more modern processors do? (No, I'm not after an exhaustive list!)Article: 156088
On a sunny day (Fri, 22 Nov 2013 10:58:58 -0800) it happened John Larkin
<jlarkin@highlandtechnology.com> wrote in
<j2av89lv8f4sbddppohnj8h1784js2c23n@4ax.com>:
>>Else you are just building an other _slow_ mobo.
>>and then may as well use this:
>> http://www.bugblat.com/products/pif/
>>
>>Without any defined spec for the application who knows?
>
>There is a perfectly good, detailed spec. You can't see it.
>
>>Ad Jim says: You are about as vague as it gets on that,
>
>I'm building a box that accepts an analog input, crunches it in
>complex ways, and makes an analog output. ZED is an ideal platform.
>All that nasty DRAM and flash and power supply stuff is done, and it
>boots Linux out of the box. Having the dual-core ARM and the FPGA on
>the same chip is cool, because it avoids a lot of interconnect between
>two chips on a board. Unfortunately, ARM-FPGA transactions still cross
>a clock boundary, so aren't blindingly fast.
Well you state 120 ns, I dunno,
but I can flip 10M Hz that makes 50 nS on 50 nS off on the Raspi,
without any FPGA, using GPIO.
I posted about those test results here, maybe it was actually 12 MHz,
That allows me to send real time DVB-S signals from GPIO.
because of the kernel task switching that you noticed, I added 8kx9 FIFO
to get a constant output stream.
http://panteltje.com/panteltje/raspberry_pi_dvb-s_transmitter/sendiq.c
That should not be that hard for a hardware designer,.
Considering the insane price of that Xilinx thing the choice should be even easier.
Now that free Mathematica runs on it what cannot be done...
But Mathematica is of course very slow on it, but no math limits.
When it MUST be FPGA for some part of the project bugblat can for example do your vector math.
http://www.bugblat.com/products/pif/
It has also enough on board RAM to make a FIFO IIRC.
What your programmers took a WEEK?? to do is already working in several languages there.
I know the value of saying 'Look We Have The Latest ZZZZZZZ' and that _could_ impress a customer,
IF he knows something, but usually they do not care how you do it if it contained horse shit and beats
their expectations fine, I think that those were Kennedy's ('s OK now? hehe) words,
Nothing to argue, It is your show. There are many channels.
I have heard Monty Python wants to do a come back, I have never even watched the stuff ever.
So, I will spend some time playing with Wolfram Language (never used that) and Mathematica on my Raspi.
Very nice if him to make it available for free.
Article: 156089On 22/11/13 19:33, Jan Panteltje wrote: > Well you state 120 ns, I dunno, > but I can flip 10M Hz that makes 50 nS on 50 nS off on the Raspi, > without any FPGA, using GPIO. Small point: you're comparing frequency and conductance :) More interesting question, assuming you were actually talking about times, what's the typical and guaranteed tolerance on those times?Article: 156090
On 11/22/2013 7:20 AM, Joseph H Allen wrote: > I've been wondering if there could be a successful (not too large, > reasonable clock frequency) soft-core FPGA version of a low end variant of > the Mill. One issue with FPGAs is that only two-port memory is available. > It's not so hard to make extra read ports with these, but extra write ports > are a big problem. This pretty much precludes any sane implementation of > Tomasulo's algorithm for OOE. > > If I understand "the belt" properly, the number of write ports is set to > just the number of pipelines (or maybe to two to support the spilling). The > pipes need to be able to read from anywhere, but we can do that with extra > read ports and one extra mux stage. Anyway, it seems like a nice way to get > superscalar on an FPGA. > The belt is not implemented as SRAM, nor as a shift register. The belt is implemented in the same manner as a conventional register bypass, with bypass muxes. In the case of a conventional, the bypass mux selects are based upon qualified equals comparators. So if a source of the current operation has the same register number as the result of a previous operation, then that previous value is used as long as it is not old enough to have been written to the register file. In the case of the belt, the belt result selects are based upon qualified equals comparators also, but what is being compared are belt "temporal location" tags. The register file isn't used roughly 80% of the time, so why use it and its associated "physical location" tags? A register file can take 3 or 4 clocks for a result written to it to show up at a functional unit's source. That turns out to be on the order of average life time of a result's "temporal location" tag before it gets "incremented off the end" of the belt. So in the case of both a conventional bypass and the belt, each functional unit's source has a multiplexer to select from each possible slot result output. So each slot source has a quick path thru the result select mux for latency 1 results, and nearly a full pipe stage path thru the mux for all the rest. I hope that answers your question - I wasn't sure if it was regarding "normal" belt operation or spilling/filling for calls, returns, interrupts, traps and the like. -- Arthur Kahlich Chief Engineer Out-of-the-Box ComputingArticle: 156091
Phil Hobbs wrote: > On 11/22/2013 11:57 AM, John Larkin wrote: >> >> >> We're into this signal processing project, using a microZed/ZYNQ thing >> as the >> compute engine. >> >> After a week or so of work by an FPGA guy and a programmer, we can now >> actually >> read and write an FPGA register from a C program, and wiggle a bit on a >> connector pin. Amazingly, the uZed eval kit does not include a demo of >> this, and >> the default boot image does not configure the FPGA! >> >> We're using their build tools to embed the FPGA config into the boot >> image. We'd >> really like to be able to have a C program read a bitstream file and >> reconfigure >> the FPGA, but we haven't been able to figure that out. >> >> If we run a C program that wiggles a pin as fast as it can, we can do >> a write to >> the FPGA register about every 170 ns. Without any attempts at >> optimization (like >> dedicating the second ARM core to the loop) we see stutters (OS >> stealing our >> CPU) that last tens or hundreds of microseconds, occasionally a full >> millisecond. That might get worse if we run TCP/IP sessions or host >> web pages or >> something, so dedicating the second ARM to realtime stuff would be good. >> >> > That is amazing, especially since so many manufacturers > (*cough*ST*cough*) respond to any query by saying "Hack up the sample > code." > Or, as in my case about am ARM controller and a few instances before, ST did not answer at all. So they flew out of the design. -- Regards, Joerg http://www.analogconsultants.com/Article: 156092
youngejoe wrote: > With FPGAs, for the above mentioned project, would I would require two > development boards connected to PC1 and PC2? My initial concept was to use > 2 FPGAs resembling 2 flash drives. > No, I don't think so. Since your proposed scheme is carried out at two locations at different times, no reason you can't do that for testing. Load the encryption config into the FPGA, and encrypt a message, store on the computer. Then, load the decryption config into the same FPGA, and decrypt the stored secret message. > PGP is very interesting - employing both asymmetric and symmetric > encryption as well as digital signatures etc. I like the idea behind it. > As its software based, would it be difficult resembling it in hardware, > say on FPGAs? I'm not enough of an expert to know. But, most encryption algorithms are based on XORs and simple integer arithmetic, so most likely it would not be hard at all to implement in an FPGA. JonArticle: 156093
youngejoe <cyounge28@gmail.com> wrote: > The main guideline I'm trying to stick is an FPGA based cryptosystem. IMO there things to think about, in descending order of importance: 1. How you're going to get the data in and out of the cryptosystem 2. What are the constraints on performance 3. What crypto you're going to do Don't get distracted about 3, that's the easy bit. If you aren't too fussed on speed, I'd try and get a soft processor system up on the FPGA, for example NIOS II or Microblaze. If you already have an FPGA board, maybe there's a demo project. This will give you a familiar means of taking to something on the board and pushing data in and out, using something like C. There will be lots of what seems to be voodoo in getting there, but hopefully someone else has done the voodoo for you. You might learn something along the way too. Then you can make peripherals that do crypto, and plug them into the system. If you're doing it bare metal, you need to push data in and out yourself. The simplest way might be a parallel port connected to some pins on the FPGA, and maybe another parallel port to collect the answer. But you'd probably have to do some soldering for this - FPGAs don't come with handy parallel ports as standard (even ones routed over USB). If you were making, say, a secure telephone then it would be easier because your board might have an ADC that would deliver regular audio samples that you could drive through your crypto and send down a wire to the other end. Then you can do everything in the FPGA without needing much help from a processor (key management is the tricky bit). Once you have something that delivers a pile of bits in and collects a pile of bits at the output, then you can start thinking about crypto. If you want to make something useful to other people, then you need to pick an application where FPGA is well suited. PCIe crypto accelerator for SSL, for example. But that's more complex and not good as a starter project. TheoArticle: 156094
Kip Ingram wrote: > Hi Jurgen. Sorry to join the party late. I tend to buck the > conventional wisdom on things like this. I did my first programmable > logic design back in the 1980's when we used PALs (22V10, etc.) > Generally you took *total* control of your design. You could use > equations, but even when I did I liked knowing exactly what was going on > with each and every fuse. With even the smallest modern FPGAs having 500K + "fuses", ie. configuration bits, it would be a very daunting task to know what they all do! Also, for design security and manufacturer's protection of their internal IP, they are getting VERY secretive of the internals. JonArticle: 156095
On Fri, 22 Nov 2013 19:33:38 GMT, Jan Panteltje
<pNaonStpealmtje@yahoo.com> wrote:
>On a sunny day (Fri, 22 Nov 2013 10:58:58 -0800) it happened John Larkin
><jlarkin@highlandtechnology.com> wrote in
><j2av89lv8f4sbddppohnj8h1784js2c23n@4ax.com>:
>
>>>Else you are just building an other _slow_ mobo.
>>>and then may as well use this:
>>> http://www.bugblat.com/products/pif/
>>>
>>>Without any defined spec for the application who knows?
>>
>>There is a perfectly good, detailed spec. You can't see it.
>>
>>>Ad Jim says: You are about as vague as it gets on that,
>>
>>I'm building a box that accepts an analog input, crunches it in
>>complex ways, and makes an analog output. ZED is an ideal platform.
>>All that nasty DRAM and flash and power supply stuff is done, and it
>>boots Linux out of the box. Having the dual-core ARM and the FPGA on
>>the same chip is cool, because it avoids a lot of interconnect between
>>two chips on a board. Unfortunately, ARM-FPGA transactions still cross
>>a clock boundary, so aren't blindingly fast.
>
>Well you state 120 ns, I dunno,
>but I can flip 10M Hz that makes 50 nS on 50 nS off on the Raspi,
>without any FPGA, using GPIO.
I haven't tried it, but I'm sure the 600 MHz ARM dio pins are faster.
The ARM transactions into the FPGA pass through the AMBA bus thing
into the FPGA clock domain, and that slows things down. It's probably
one of those modern situations that trades DMA throughput against
single-transaction latency.
>I posted about those test results here, maybe it was actually 12 MHz,
>That allows me to send real time DVB-S signals from GPIO.
>because of the kernel task switching that you noticed, I added 8kx9 FIFO
>to get a constant output stream.
> http://panteltje.com/panteltje/raspberry_pi_dvb-s_transmitter/sendiq.c
>That should not be that hard for a hardware designer,.
>Considering the insane price of that Xilinx thing the choice should be even easier.
The uZed is only about $200, a pretty good deal for all the stuff that
it does. It's something like a 12 or 14 layer board.
>Now that free Mathematica runs on it what cannot be done...
>But Mathematica is of course very slow on it, but no math limits.
>When it MUST be FPGA for some part of the project bugblat can for example do your vector math.
> http://www.bugblat.com/products/pif/
>It has also enough on board RAM to make a FIFO IIRC.
>What your programmers took a WEEK?? to do is already working in several languages there.
>
>I know the value of saying 'Look We Have The Latest ZZZZZZZ' and that _could_ impress a customer,
>IF he knows something, but usually they do not care how you do it if it contained horse shit and beats
>their expectations fine, I think that those were Kennedy's ('s OK now? hehe) words,
>
>Nothing to argue, It is your show. There are many channels.
>I have heard Monty Python wants to do a come back, I have never even watched the stuff ever.
They were fabulous. Dead parrots. Gas cookers. Exploding version of
the 1812 Overture. Lumberjack Song. Twit Races. Cartoons. Get some
DVDs.
--
John Larkin Highland Technology, Inc
jlarkin at highlandtechnology dot com
http://www.highlandtechnology.com
Precision electronic instrumentation
Picosecond-resolution Digital Delay and Pulse generators
Custom laser drivers and controllers
Photonics and fiberoptic TTL data links
VME thermocouple, LVDT, synchro acquisition and simulation
Article: 156096In sci.electronics.design John Larkin <jlarkin@highlandtechnology.com> wrote: > We're running the Linux that comes installed on the uZed. This is more true for desktop-y Linux than it is for embedded, but sometimes it pays to recompile the kernel and customize it to your needs. There are some choices in the scheduler that can be tweaked this way. This can also be a good way to get a kernel that just doesn't work at all, so make sure you have a way to go back to stock. The kernel configuration for plain old x86 is pretty good about dependencies: if you turn on kernel feature X, it will tell you that you need to turn on Y and Z as well to get X to work, and maybe even do it for you. Linux for embedded CPUs varies - sometimes it's like x86, and sometimes there is precisely one (undocumented) combination of kernel build options that actually works. Sometimes the documentation exists, but it's on the wrong side of an E[STF]L barrier. Back to your original point, sometimes the lack of sample code is down to the vendor being clueless. Sometimes there is another reason - if you get the hard sell for using their approved development partners, that's a hint. > There's probably some way to make Linux run the realtime app on the > second ARM core. taskset(1) from the command line if they gave you that, sched_setaffinity(2) if they didn't. > I guess we could even force that to run bare-metal code if we had to. I am pretty sure that you can tell Linux at boot time to not use some of the cores, but I'm not sure how you would then get something else to run on the cores that Linux isn't suing. > I have been pressured for some time now to run C apps inside an FPGA, > in a soft core processor, microBlaze or whatever. That never made > sense to me, eating all those FPGA resources to get a pokey CPU with > a tiny memory space. I heard this too, and my objection (from the software side) was that in my experience, the hardware guys I worked with tended to be pretty bad at revision control for FPGAs. Part of this was down to the FPGA tools, and part of it was down to an "it's hardware and we'll never have to change it" attitude, so they wouldn't leave a way to update the soft core over the phone. I think I have ranted about this before. :) I like the hard core idea better, as long as the stuff that runs on the hard core loads up like normal, and is not embedded in some huge binary blob puked out by the FPGA tools. Matt RoberdsArticle: 156097
In comp.arch.fpga Joseph H Allen <jhallen@theworld.com> wrote: > I've been wondering if there could be a successful (not too large, > reasonable clock frequency) soft-core FPGA version of a low end variant of > the Mill. One issue with FPGAs is that only two-port memory is available. > It's not so hard to make extra read ports with these, but extra write > ports are a big problem. This pretty much precludes any sane > implementation of Tomasulo's algorithm for OOE. I have wondered about an FPGA implementation of the 360/91, I believe where Tomasulo's algorithm was developed. As far as I know, though, not enough details are available. -- glenArticle: 156098
On Monday, November 11, 2013 2:40:56 PM UTC-8, Jon Elson wrote: > I've been using Ise WebPack 10.1 for some time, as it is the last version >=20 > that supported the Spartan 2E chips. I don't do a lot on the >=20 > 2E anymore, but there are a number of units in the field with >=20 > those chips. Anyway, I'm still using Spartan 3A and 3AN, as >=20 > well as 9500XL and Coolrunner II CPLDs. I recently realized >=20 > my main desktop computer has been running 12 years straight, >=20 > and is probably living on borrowed time. So, I'm trying to >=20 > set up a new system. Xilinx doesn't allow WebPack 10.1 to >=20 > run on X86_64 systems, but some people report workarounds. >=20 > So far, I have not gotten it to install on Linux. I >=20 > installed the 32-bit libraries and bypassed the first-level >=20 > setup script, but I get to a page where you enter your >=20 > Xilinx registration code, and then it allows you to select the >=20 > components you want, but WebPack is greyed out. So, apparently >=20 > at that script it also detects the 64-bit system. >=20 >=20 >=20 > Then, I tried downloading the current version of Vivado WebPack, >=20 > but it supports only a VERY small range of -7 parts, and no >=20 > CPLDs. Didn't seem like a very useful piece of software. >=20 > And, there's no way I can afford $4000 to be allowed to run >=20 > 5-year old software. What gives? WebPack used to be a completely >=20 > viable option for developing on the mid-range parts from >=20 > several families. >=20 >=20 >=20 > I'm going to try copying over all my files from the 10.1 >=20 > install on the old machine and see if that works. If not, does >=20 > anyone know what older Ise Webpack will support Spartan 3A >=20 > plus CPLD's and run on a 64-bit Linux system? I tried looking >=20 > this up on Xilinx.com, but it was REALLY difficult to find any >=20 > mention of what chips are supported by what software. >=20 >=20 >=20 > Thanks for any tips! >=20 >=20 >=20 > Jon I have no issues running the command line 10.1 tools on Win7pro 64 bit. I'v= e no use for any of the GUI components, so I can't vouch for that. I don't = install though. I keep a zip file that is the installation folder of the 10= .1 tools from long ago. I mount that as a drive using a zip mount utility. = I point my $XILINX environment variable to the mounted drive, and I can run= the command line tools just fine. I preserve a number of the old versions = of tools this way to support various old designs from time to time. I just = carry those zip files forward to new machines. Very easy to migrate.Article: 156099
In article <l6oir7$am4$1@speranza.aioe.org>,
glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:
>In comp.arch.fpga Joseph H Allen <jhallen@theworld.com> wrote:
>> I've been wondering if there could be a successful (not too large,
>> reasonable clock frequency) soft-core FPGA version of a low end variant of
>> the Mill. One issue with FPGAs is that only two-port memory is available.
>> It's not so hard to make extra read ports with these, but extra write
>> ports are a big problem. This pretty much precludes any sane
>> implementation of Tomasulo's algorithm for OOE.
>I have wondered about an FPGA implementation of the 360/91,
>I believe where Tomasulo's algorithm was developed.
>As far as I know, though, not enough details are available.
Heh, if you are really brave, start Herrmannsfeldt Corporation (like Amdahl
Corporation): make an FPGA implementation of any recent (64-bit) IBM
mainframe- probably there is a market even if it's a slow, simple in-order
single-issue design. Use the Hercules emulator as the predictor in your
design verification suite.
--
/* jhallen@world.std.com AB1GO */ /* Joseph H. Allen */
int a[1817];main(z,p,q,r){for(p=80;q+p-80;p-=2*a[p])for(z=9;z--;)q=3&(r=time(0)
+r*57)/7,q=q?q-1?q-2?1-p%79?-1:0:p%79-77?1:0:p<1659?79:0:p>158?-79:0,q?!a[p+q*2
]?a[p+=a[p+=q]=q]=q:0:0;for(;q++-1817;)printf(q%79?"%c":"%c\n"," #"[!a[q-1]]);}
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