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
>>>>>>> How to make master FPGA to connect to many FPGAs ? >>>>>>> >>>>>>> Two FPGAs connected by serial TDI - TDO, and two fpgas TMS TCK >>>>>>> TDO and TDI connect to master fpga, master fpga has TMS TDI TDO >>>>>>> TCK connected and working to pc normally, it need to make >>>>>>> connection JTAG of two fpgas to other 4 ports or somehow can >>>>>>> connect to master's jtag port ? >>>>>> >>>>>> | |---------|-TMS----|------------|-TMS---- >>>>>> | | FPGA 0 |-TCK----| |-TCK---- >>>>>> | | |-TDO----| |-TDO---- >>>>>> | |---------| | |-TDI---- >>>>>> | | | | >>>>>> | TDI | | >>>>>> | | | | >>>>>> | | | MASTER FPGA| >>>>>> | | | | >>>>>> | TDO | | >>>>>> | | | | >>>>>> | |---------|-TMS----| | >>>>>> | | FGPA 1 |-TCK----| | >>>>>> | | |-TDI----| | >>>>>> | |---------| |------------| >>>>>> >>>>> >>>>> Why do you want the master FPGA to control the others rather than >>>>> loading them all in one chain? Connect all TMS and TCK lines in >>>>> parallel and connect all TDI and TDO in one big daisy chain. If the >>>>> slave FPGAs are loaded by the master, where will the data come from? >>>> It is reverse engineering, someone did this but i just want reuse >>>> board only >>> >>> The JTAG signals to the master chip, do they connect to general I/Os as >>> well as to the FPGA JTAG signals? Or just JTAG or just I/Os? >>> >>> You didn't say where you expect the data to come from to program the >>> chained slave FPGAs. Is it supposed to come from the main JTAG port as >>> if it was talking to the slave chain? Or will the master FPGA have a >>> separate interface from an MCU or a Flash chip? >>> >>> What is your overall plan? >> Slave FPGAs connects to USER I/O ports. for example: >> TMS of salve FPGA chip connects to user i/o pin CC >> TDI of slave FPGA chip connects to user i/0 pin VRP >> TCK of slave FPGA ship connects to user i/o pin CC > > What do you connect the user I/O of the master to internally? If you > try using the JTAG on the master it will control the master, no? > Perhaps you are looking for something similar like Altera JAM Player for embedded. Take a look here https://www.altera.com/support/support-resources/support-centers/devices/programming-tools/jam-stapl/tls-jam-embedded.html There is pice of C code able to send chip image from embedded system to another fpga. Unfortunatell I don't know X as good as I would like to. BR AdamArticle: 159826
In article <3f49ff11-d6b9-4772-b626-ff6e87ecf04b@googlegroups.com>, Svenn Are Bjerkem <svenn.bjerkem@gmail.com> wrote: >Hi, >has anybody simulated PCIe at TLP level? I would like to feed a 1x PCIe >endpoint interface with data as if it was inserted into a host PCIe slot. > >I need some pointers to documents or code describing what I have to do >to make a simplem memory read and memory write. Svenn, There's multiple ways to tackle this. Since this is an FPGA group, one assumes you're implementing this on an FPGA. Xilinx for example will generate some sort of example design which you can run in your favorite simulator, and watch your TLP packets pass by. Hack at it and recode as you see fit. Normally, if your implementing an PCIE endpoint within and FPGA, the generated example will just insert an equivalent root complex inside the testbench to manage the low-level PCIE negotiations, etc. Other options include purchasing PCIE verification IP from a vendor. There's many options here. Other options include writing your own PCIE TLP source/sync models (at perhaps a higher level), and tying that up in your testbench. There's many options here to explore, all depending on your requirements. Good luck. --MarkArticle: 159827
On Friday, February 7, 2003 at 7:02:37 PM UTC+5:30, llaa57 wrote: > I implemented the circuit described in the application note "Unusual > clock dividers" written by Peter Alfke: > http://www.xilinx.com/xcell/xl33/xl33_30.pdf. > I used a Xilinx XC9536 and the input clock is generated by an > oscillator (SCO-061S 48MHz) by Sunny. > My problem is that the output clock's duty cycle is 33% and not 50% as > expected. Why? Is the CPLD unsuitable for this circuit? > > Many thanks in advance. Hi All, I'm trying to implement the frequency divider of 1.5 for 100mhz clock frequency. i need to obtain 65mhz as output. i'm using xc6slx16 fpga..could anyone help me with vhdl codes for the above..No problem with duty cycle.. Thanks all.Article: 159828
vjkaran19@gmail.com wrote: > On Friday, February 7, 2003 at 7:02:37 PM UTC+5:30, llaa57 wrote: >> I implemented the circuit described in the application note "Unusual >> clock dividers" written by Peter Alfke: >> http://www.xilinx.com/xcell/xl33/xl33_30.pdf. >> I used a Xilinx XC9536 and the input clock is generated by an >> oscillator (SCO-061S 48MHz) by Sunny. >> My problem is that the output clock's duty cycle is 33% and not 50% as >> expected. Why? Is the CPLD unsuitable for this circuit? >> >> Many thanks in advance. > > Hi All, > I'm trying to implement the frequency divider of 1.5 for 100mhz clock frequency. i need to obtain 65mhz as output. i'm using xc6slx16 fpga..could anyone help me with vhdl codes for the above..No problem with duty cycle.. > > Thanks all. Capturing a thread that old is evil! Why don' you start a new thread? 100 /1.5 != 65? For a 66,666_ clock, use a DCM clock module and first multiply by 2 and then divide by 3. Bye -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 1623569 ------- Fax. 06151 1623305 ---------Article: 159829
On Friday, February 7, 2003 at 7:02:37 PM UTC+5:30, llaa57 wrote:
> I implemented the circuit described in the application note "Unusual
> clock dividers" written by Peter Alfke:
> http://www.xilinx.com/xcell/xl33/xl33_30.pdf.
> I used a Xilinx XC9536 and the input clock is generated by an
> oscillator (SCO-061S 48MHz) by Sunny.
> My problem is that the output clock's duty cycle is 33% and not 50% as
> expected. Why? Is the CPLD unsuitable for this circuit?
>
> Many thanks in advance.
Hi,
Thanks to all..
Article: 159830
Hi,
Last weekend, I was continueing on my small project to use a FPGA as
DAC. I now use a hardware DAC (tlc5615).
So I have two modules, a top-level module for the DDS and an additional
module to drive the TLC. I have two signal for handshacking ("load" and
"done").
At a certain point, I had the problem that one of the signals wasn't
dropped fast enough, which resulted in a weird timing-issue.
In the end, I managed to fix my particular by adding a state with a
small delay in my FSM, but -looking back- it is probably also possible
to have done this with some additional checks in the state-machine.
Question: are there known "best practices" when designing a
handshacking-protocol between different modules in a FPGA design?
Is there documentation about this? Or text-books?
My question is not about this particular bug but a generic question on
"do-s" and "do not-s" in general.
Kristoff
Article: 159831In article <oc0cog$j4c$1@dont-email.me>, kristoff <kristoff@skypro.be> wrote: >Hi, > >Question: are there known "best practices" when designing a >handshacking-protocol between different modules in a FPGA design? >Is there documentation about this? Or text-books? > > >My question is not about this particular bug but a generic question on >"do-s" and "do not-s" in general. I like the handhaking done in the various AXI like protocol's from ARM - basically "VALID", "READY" signals. The key to making things work is there's NO combinational paths between a VALID and a READY port i.e. the protocol is fully synchronous with all module I/O registered. Asynch handshaking is another beast altogether. I'm assuming you're not talking about that. Do a web search on the AXI protocols. ARM's specific document is titled "AMBA AXI and ACE Protocol Specification". The handshaking is described in section A3.2.1 Regards, MarkArticle: 159832
Hi Mark, On 04-04-17 18:03, Mark Curry wrote: > In article <oc0cog$j4c$1@dont-email.me>, kristoff <kristoff@skypro.be> wrote: >> Question: are there known "best practices" when designing a >> handshacking-protocol between different modules in a FPGA design? >> Is there documentation about this? Or text-books? >> >> >> My question is not about this particular bug but a generic question on >> "do-s" and "do not-s" in general. > I like the handhaking done in the various AXI like protocol's from ARM - > basically "VALID", "READY" signals. The key to making things work is there's > NO combinational paths between a VALID and a READY port i.e. the protocol is > fully synchronous with all module I/O registered. (...) > Do a web search on the AXI protocols. ARM's specific document is titled > "AMBA AXI and ACE Protocol Specification". The handshaking is described > in section A3.2.1 Thanks for the link. Very interesting reading. Yes, the handshaking protocol I used was syncronised, but I only used the positive edge of the clock. The AXI protocol used the positive edge of the clock to set the control-signals and the negative edge of the clock to clear them. That's indeed a good idea. I'll try to use this in my handshaking mechanism to try to make it more robust. > Regards, > Mark KristoffArticle: 159833
On 4/4/2017 11:08 AM, kristoff wrote:
> Hi,
>
>
> Last weekend, I was continueing on my small project to use a FPGA as
> DAC. I now use a hardware DAC (tlc5615).
>
>
> So I have two modules, a top-level module for the DDS and an additional
> module to drive the TLC. I have two signal for handshacking ("load" and
> "done").
> At a certain point, I had the problem that one of the signals wasn't
> dropped fast enough, which resulted in a weird timing-issue.
>
> In the end, I managed to fix my particular by adding a state with a
> small delay in my FSM, but -looking back- it is probably also possible
> to have done this with some additional checks in the state-machine.
>
>
>
> Question: are there known "best practices" when designing a
> handshacking-protocol between different modules in a FPGA design?
> Is there documentation about this? Or text-books?
>
>
> My question is not about this particular bug but a generic question on
> "do-s" and "do not-s" in general.
I've not used handshakes very often. What would be going on that a
handshake is required? Are you talking about clock domain crossing? Or
are you talking about two FSMs talking to each other. In both cases I
use a direct handshake where one signal does not change state until the
other "sees" it and acknowledges the previous change.
0,0 -> 1,0 -> 1,1 -> 0,1 -> 0,0
This has no opportunity for a race or timing problem. Is there
something I am missing?
--
Rick C
Article: 159834On 4/4/2017 3:36 PM, kristoff wrote: > > On 04-04-17 18:03, Mark Curry wrote: > (...) >> Do a web search on the AXI protocols. ARM's specific document is titled >> "AMBA AXI and ACE Protocol Specification". The handshaking is described >> in section A3.2.1 > > > Thanks for the link. Very interesting reading. > > Yes, the handshaking protocol I used was syncronised, but I only used > the positive edge of the clock. > > The AXI protocol used the positive edge of the clock to set the > control-signals and the negative edge of the clock to clear them. > > That's indeed a good idea. I'll try to use this in my handshaking > mechanism to try to make it more robust. Looking at section A3.2 I don't see any signals changing state on the falling edge of the clock. Where do you see this? It is *very* hard to design synchronous logic that operates on both edges of the clock. The two sides of an interface can operate on different clock edges, but this only gives half a clock cycle for timing. Am I completely missing something? -- Rick CArticle: 159835
On 04/04/2017 12:36 PM, kristoff wrote: > Hi Mark, > > > > > On 04-04-17 18:03, Mark Curry wrote: >> In article <oc0cog$j4c$1@dont-email.me>, kristoff >> <kristoff@skypro.be> wrote: > >>> Question: are there known "best practices" when designing a >>> handshacking-protocol between different modules in a FPGA design? >>> Is there documentation about this? Or text-books? >>> >>> >>> My question is not about this particular bug but a generic question on >>> "do-s" and "do not-s" in general. > >> I like the handhaking done in the various AXI like protocol's from ARM - >> basically "VALID", "READY" signals. The key to making things work is >> there's >> NO combinational paths between a VALID and a READY port i.e. the >> protocol is >> fully synchronous with all module I/O registered. > (...) >> Do a web search on the AXI protocols. ARM's specific document is titled >> "AMBA AXI and ACE Protocol Specification". The handshaking is described >> in section A3.2.1 > > > Thanks for the link. Very interesting reading. > > Yes, the handshaking protocol I used was syncronised, but I only used > the positive edge of the clock. > > The AXI protocol used the positive edge of the clock to set the > control-signals and the negative edge of the clock to clear them. > > That's indeed a good idea. I'll try to use this in my handshaking > mechanism to try to make it more robust. > > >> Regards, >> Mark > Kristoff > NO NO NO STOP STOP STOP. The AXI handshake protocols DO NOT do that. They are, like all good synchronous logic should be, sensitive only to the rising edge of the clock. What the AXI handshake protocol does is use the concept of "mutually agreed upon". If at the rising clock edge a) the master has already asserted VALID and b) the slave has already asserted READY, then the information present on all the rest of the wires is agreed to have been handed off from the master to the slave. Otherwise, that information (if available) is still the master's responsibility. The point is that there's no need for a recovery cycle. The master can leave VALID asserted and change to new valid data. The slave can leave READY asserted if it doesn't need to wait while it processes the data that it just picked up, and the next information can be transferred on the very next rising edge. But this comes with the requirement that whether the master's data is valid is entirely uninformed by whether the slave is ready for it and vice versa. -- Rob Gaddi, Highland Technology -- www.highlandtechnology.com Email address domain is currently out of order. See above to fix.Article: 159836
Hi Rob, On 04-04-17 22:20, Rob Gaddi wrote: >> Yes, the handshaking protocol I used was syncronised, but I only used >> the positive edge of the clock. >> The AXI protocol used the positive edge of the clock to set the >> control-signals and the negative edge of the clock to clear them. > NO NO NO STOP STOP STOP. > > The AXI handshake protocols DO NOT do that. They are, like all good > synchronous logic should be, sensitive only to the rising edge of the > clock. Hum. You are correct (as also noted by Rick). I misread the timing. My error. My appologies. > What the AXI handshake protocol does is use the concept of "mutually > agreed upon". If at the rising clock edge a) the master has already > asserted VALID and b) the slave has already asserted READY, then the > information present on all the rest of the wires is agreed to have been > handed off from the master to the slave. Otherwise, that information > (if available) is still the master's responsibility. Well, what I had was a bit like that. I have a signal "load" (equivalent to "valid" in the AXI handshake) and "done" (equivalent to "not ready" in AXI). The master is the top-level module: the DDS module The slave is a a module that writes out a value to the SPI interface. The problem I had (at least in the simulator), was a timing-issue: - In the AXI process, when the slave has received its data, it drops the "ready" line, indicating that the slave is still working on the data it has justreceived (in my case, it is still sending it out the SPI interface). In the simulation of my design, this "drop ready line" event took 1 clock-cyclus. (the slave need to detect this bit-change, clear the "ready" line and sends this signal back to the master) - However, by the time that this signal did arrived at the master, the master module had gone to the next steps in its FSM: "wait for the slave to indicate it is ready to receive new data (i.e. ready is high), if ready: continue". As the "not ready" signal of the slave had not yet arrived, the top-block happily said "ready line is high, so the slave is ready, so let's go on". And, and additional issue, as the FSM of the master had just checked the "ready" signal, it simply went on to calculate the next DDS value and then the "trigger the slave to read the next value" stage, all this without without checking that signal again. In short, the bug was the result of this assumption: "When the slave notifies that the master that is not-ready to receive any more data, this signal arrives in time for the state-machine of the master to process it correctly." In my case, that assumpion turned out to be wrong. In my case, I fixed this with a small delay in the FSM, but I guess it makes more sence to always do a "check if slave is ready" JUST BEFORE sending the data to it. Therefor my question for "do's and dont's" when designing a protocol that controls dataflow between two modules. I guess -especially if you are designing modules that get on github and will be used by others- it is logical to apply more "strict" rules to these parts of the code that interfaces with code written by other people. KristoffArticle: 159837
ISPVM 18.1 and ISP (HW-USBN-2A) are connecting and downloading and it says that there is no information of ISPLSI 1032 Chip continuously. I tested 10 boards and it is hard because I have the same problem. I would like to help you. Lattices Know how to download ISPLSI 1032 and Jtag / ISP cable and how to get the program.Article: 159838
We have a ZYNQ whose predicted timing isn't meeting decent margins. And we don't want a lot of output pin timing variation in real life. We can measure the chip temperature with the XADC thing. So, why not make an on-chip heater? Use a PLL to clock a bunch of flops, and vary the PLL output frequency to keep the chip temp roughly constant. -- John Larkin Highland Technology, Inc picosecond timing precision measurement jlarkin att highlandtechnology dott com http://www.highlandtechnology.comArticle: 159839
On Mon, 10 Apr 2017 18:13:13 -0700, John Larkin <jjlarkin@highland_snip_technology.com> wrote: >We have a ZYNQ whose predicted timing isn't meeting decent margins. >And we don't want a lot of output pin timing variation in real life. > >We can measure the chip temperature with the XADC thing. So, why not >make an on-chip heater? Use a PLL to clock a bunch of flops, and vary >the PLL output frequency to keep the chip temp roughly constant. Why not? Don't bother with the output frequency, just vary the number of flops wiggling.Article: 159840
On Mon, 10 Apr 2017 22:15:50 -0400, krw@notreal.com wrote: >On Mon, 10 Apr 2017 18:13:13 -0700, John Larkin ><jjlarkin@highland_snip_technology.com> wrote: > >>We have a ZYNQ whose predicted timing isn't meeting decent margins. >>And we don't want a lot of output pin timing variation in real life. >> >>We can measure the chip temperature with the XADC thing. So, why not >>make an on-chip heater? Use a PLL to clock a bunch of flops, and vary >>the PLL output frequency to keep the chip temp roughly constant. > >Why not? Don't bother with the output frequency, just vary the number >of flops wiggling. That would work too. Maybe have a 2-bit heat control word, to get coarse steps of power dissipation, 4 groups of flops. I suppose a single on-off bit could be a simple bang-bang thermostat. The PLL thing would be elegant, proportional control of all the flops in the distributed heater array. I'm thinking we could reduce the overall effect of ambient temp changes by some healthy factor, 4:1 or 10:1 or something. -- John Larkin Highland Technology, Inc lunatic fringe electronicsArticle: 159841
On 4/10/2017 11:06 PM, John Larkin wrote: > On Mon, 10 Apr 2017 22:15:50 -0400, krw@notreal.com wrote: > >> On Mon, 10 Apr 2017 18:13:13 -0700, John Larkin >> <jjlarkin@highland_snip_technology.com> wrote: >> >>> We have a ZYNQ whose predicted timing isn't meeting decent margins. >>> And we don't want a lot of output pin timing variation in real life. >>> >>> We can measure the chip temperature with the XADC thing. So, why not >>> make an on-chip heater? Use a PLL to clock a bunch of flops, and vary >>> the PLL output frequency to keep the chip temp roughly constant. >> >> Why not? Don't bother with the output frequency, just vary the number >> of flops wiggling. > > That would work too. Maybe have a 2-bit heat control word, to get > coarse steps of power dissipation, 4 groups of flops. I suppose a > single on-off bit could be a simple bang-bang thermostat. > > The PLL thing would be elegant, proportional control of all the flops > in the distributed heater array. > > I'm thinking we could reduce the overall effect of ambient temp > changes by some healthy factor, 4:1 or 10:1 or something. Are the die temperature variations caused by ambient temp changes, or on chip heat generation changes? -- Rick CArticle: 159842
On Mon, 10 Apr 2017 18:13:13 -0700, the renowned John Larkin <jjlarkin@highland_snip_technology.com> wrote: >We have a ZYNQ whose predicted timing isn't meeting decent margins. >And we don't want a lot of output pin timing variation in real life. > >We can measure the chip temperature with the XADC thing. So, why not >make an on-chip heater? Use a PLL to clock a bunch of flops, and vary >the PLL output frequency to keep the chip temp roughly constant. Clever, and maybe patentable. Maybe you could servo a ring oscillator frequency to the clock by changing the dissipation and directly stabilize the timing. --sp -- Best regards, Spehro PefhanyArticle: 159843
On Tue, 11 Apr 2017 00:26:33 -0400, Spehro Pefhany <speffSNIP@interlogDOTyou.knowwhat> wrote: >On Mon, 10 Apr 2017 18:13:13 -0700, the renowned John Larkin ><jjlarkin@highland_snip_technology.com> wrote: > >>We have a ZYNQ whose predicted timing isn't meeting decent margins. >>And we don't want a lot of output pin timing variation in real life. >> >>We can measure the chip temperature with the XADC thing. So, why not >>make an on-chip heater? Use a PLL to clock a bunch of flops, and vary >>the PLL output frequency to keep the chip temp roughly constant. > >Clever, and maybe patentable. Maybe you could servo a ring oscillator >frequency to the clock by changing the dissipation and directly >stabilize the timing. > >--sp That would work too. We'd have to persuade/fool the tools into letting us build a ring oscillator! I've used ring oscillators to measure FPGA chip temp before: https://dl.dropboxusercontent.com/u/53724080/Thermal/ESM_Ring_Oscillator.jpg The change in prop delay vs temp is fairly small. -- John Larkin Highland Technology, Inc lunatic fringe electronicsArticle: 159844
John Larkin wrote: > We can measure the chip temperature with the XADC thing. So, why not > make an on-chip heater? Use a PLL to clock a bunch of flops, and vary > the PLL output frequency to keep the chip temp roughly constant. Reminds me my old idea of building domestic heaters out of Pentium4 chips. 20 chips with TDP of 135W make a decent heater and one can always sell the waste MIPS. Best regards, PiotrArticle: 159845
I am trying to use https://github.com/freecores/versatile_fft , but after I run "make all", data_out.txt and res.txt are all empty. Anyone have same experience ?Article: 159846
In comp.arch.fpga Piotr Wyderski <peter.pan@neverland.mil> wrote: > John Larkin wrote: > > > We can measure the chip temperature with the XADC thing. So, why not > > make an on-chip heater? Use a PLL to clock a bunch of flops, and vary > > the PLL output frequency to keep the chip temp roughly constant. We do that by controlling the fan speed: keeps the FPGA ~40C which is in the middle of its timing range. > Reminds me my old idea of building domestic heaters out of Pentium4 > chips. 20 chips with TDP of 135W make a decent heater and one can > always sell the waste MIPS. BTDT. It's not as simple as that, because CPUs are point heat sources. To distribute the heat (and stop them melting) you need decent heatsinks and cooling. Servers, which do useful compute and emit waste heat, tend to be cooled assuming a high-velocity, high-noise environment. Domestic heating wants low-velocity, low-noise - which needs different enclosure and cooling arrangements. The system ends up being substantially custom by the end of it. You can get a long way with a dual-socket server board (~400W) in a 'workstation' case, but it's quite space-inefficient. You can't pack CPUs too closely together, first for thermal reasons but also because RAM and IO take up board area. (Blade servers do that, but again they're designed for fast air cooling). Unless you plan to put your 'furnace' in the basement with enough sound insulation to deaden the howling fans. Or watercool - needing most custom stuff. TheoArticle: 159847
On Tue, 11 Apr 2017 07:48:17 +0200, Piotr Wyderski <peter.pan@neverland.mil> wrote: >John Larkin wrote: > >> We can measure the chip temperature with the XADC thing. So, why not >> make an on-chip heater? Use a PLL to clock a bunch of flops, and vary >> the PLL output frequency to keep the chip temp roughly constant. > >Reminds me my old idea of building domestic heaters out of Pentium4 >chips. 20 chips with TDP of 135W make a decent heater and one can >always sell the waste MIPS. > > Best regards, Piotr > What a waste of Pentium chips. They make such excellent x-acto knife sharpeners. -- John Larkin Highland Technology, Inc lunatic fringe electronicsArticle: 159848
On 11 Apr 2017 12:26:08 +0100 (BST), Theo Markettos <theom+news@chiark.greenend.org.uk> wrote: >In comp.arch.fpga Piotr Wyderski <peter.pan@neverland.mil> wrote: >> John Larkin wrote: >> >> > We can measure the chip temperature with the XADC thing. So, why not >> > make an on-chip heater? Use a PLL to clock a bunch of flops, and vary >> > the PLL output frequency to keep the chip temp roughly constant. > >We do that by controlling the fan speed: keeps the FPGA ~40C which is in the >middle of its timing range. We do have provision for adding a pin-fin heat sink and a fan directly over the chip. Like this: https://dl.dropboxusercontent.com/u/53724080/Thermal/Uzed_Fan_Side.JPG Just yesterday someone was harassing me to make the fan speed software controllable, so maybe I will. I'd rather not have an FPGA fan, but it's pretty likely we'll need it. There will be an overall box fan, and it is speed controlled. https://dl.dropboxusercontent.com/u/53724080/Circuits/Power/Fan_Regulator.jpg -- John Larkin Highland Technology, Inc lunatic fringe electronicsArticle: 159849
On Mon, 10 Apr 2017 22:53:54 -0700, _Xilinx wrote: > I am trying to use https://github.com/freecores/versatile_fft , but > after I run "make all", data_out.txt and res.txt are all empty. > > Anyone have same experience ? Are you feeding it real inputs and doing anything with the outputs? Synthesis tools are really good at figuring out what logic isn't being used, and trimming it. It's pretty common to make something just to see if it'll synthesize and find out that it's not there because you gave it constant inputs or didn't bring the outputs to pins. -- 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