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 Nov 30, 8:46=A0am, rickman <gnu...@gmail.com> wrote: > On Nov 30, 2:35=A0am, Newman <newman5...@yahoo.com> wrote: > > > > > On Nov 29, 11:54=A0pm, rickman <gnu...@gmail.com> wrote: > > > > I'm not sure what is wrong here. I have a design that I have used in > > > the past and has worked ok. I am making modifications to it and my Hi= - > > > Z outputs are being grounded. This creates some problems during > > > operation. The VHDL code is like this... > > > > TMS_B1 <=3D 'Z'; > > > > I just want this output to be Hi-Z for this design so that the pin > > > output is not driven (which clobbers these signals from other > > > sources). The lines for this output in the preference file are... > > > > LOCATE COMP "TMS_B1" SITE "36" ; > > > IOBUF PORT "TMS_B1" IO_TYPE=3DLVCMOS33 PULLMODE=3DKEEPER DRIVE=3D8 > > > SLEWRATE=3DSLOW ; > > > > When I load the design into the part, the output is always low and > > > checking the design in Epic, I see the tri-state driver has a 0 on th= e > > > input and a 0 on the enable. I believe the 0 on the enable turns on > > > the output driver because that is how the outputs are configured. > > > > I also looked at the Technology View in Synplify and I find TMS_B1 is > > > driven by a OB with a 0 on it's input. > > > > Is this a bug or is there something wrong with the way I am doing > > > this? I made a lot of changes to the overall design before I > > > discovered this bug so I'm not certain that the preference file lines > > > have not been changed since this was working, but I don't see how the= y > > > can be causing this problem. > > > > Rick > > > Rick, > > I suppose you have already convinced yourself that it is not the > > buskeeper circuit driving the line low. > > > Bus Maintenance Circuit > > Each pad has a weak pull-up, weak pull-down and weak buskeeper > > capability. The pull-up and pull-down settings > > offer a fixed characteristic, which is useful in creating wired logic > > such as wired ORs. However, current can be > > slightly higher than other options, depending on the signal state. The > > bus-keeper option latches the signal in the > > last driven state, holding it at a valid level with minimal power > > dissipation. Users can also choose to turn off the bus > > maintenance circuitry, minimizing power dissipation and input leakage. > > Note that in this case, it is important to > > ensure that inputs are driven to a known state to avoid unnecessary > > power dissipation in the input buffer. > > Thanks for the suggestion, but yes, I eliminated that by looking at > the I/O block settings in Epic, the layout editor. =A0I originally saw > this problem with an LED driving pin. =A0I set it for hi-z and it was > driving the LED on hard. =A0A bus keeper wouldn't drive that hard. > Besides, this pin is driving two LEDs, one up and one down. =A0Hi-z is > the only state where neither LED is on. =A0When I use logic to select > the three states, 1, 0, Z; then the hi-z state is enabled > appropriately. > > I can always work around this by controlling it from some signal such > as reset so that it is always hi-z after the FPGA is up. =A0It is odd > that this worked just fine before and now screws up. =A0I haven't > updated any of the development software that I know of, but I haven't > messed with this design since 2008, so there's been a lot of water > under the dam since then. =A0If it is a tool problem, I may not get an > update. =A0My maintenance ran out long ago and this is a paid for copy. > I'd hate to have to shell out a kilobuck to get a bug fix so I can > continue using the software that I already paid for. > > Rick This looks remarkably like something I remember from older Xilinx projects where assigning an output to 'Z' effectively removed it from the design. (the output isn't "driven" so get rid of it) Then the default action for the backend tools is to take any undriven outputs and ground them (you must have forgotten to assign a value to this). What would happen if you changed the output so it is only tristate under some condition? You could pick some condition that you know is always true, but the synthesizer can't guess, or make the output briefly drive (high or low) as the design comes out of reset. Does your project perhaps have a setting or unused IOB's to be "virtual grounds"? All I can think of... -- GaborArticle: 149876
I have a FPGA project and it needs to interface with my PC. The problem I've run into is finding a fast form of communication with very low latency. I've come asking for advice and possible solution. I need a link that can transfer 1KB 1200 times every second, not just 1.2MB a second because the input is dependent on the output. The latency issue makes USB impossible and a normal serial port doesnt have the bandwidth. My initial inclination was to use a IEEE 1394 connection but the interface driver ICs are both expensive and too small to solder. I've looked for an HDL implementation of the driver but I cannot find one. Does anyone know of a way to interface with a PC that can be or has been implemented on a FPGA or has a low component count? --------------------------------------- Posted through http://www.FPGARelated.comArticle: 149877
On Nov 30, 9:30=A0am, mksuth <mksutherla...@gmail.com> wrote: > The fpga board will mate with a single board PC which only has a PCI > interface (actually it is a PC/104+ stackable interface). > > On Nov 30, 9:21=A0am, "maxascent" > > <maxascent@n_o_s_p_a_m.n_o_s_p_a_m.yahoo.co.uk> wrote: > > Why are you using PCI? Why not PCI Express? I would of thought PCI is > > pretty much dead now. All the new FPGA devices, even the cheap ones sup= port > > PCI Express so you may be better looking at that route. > > > Jon =A0 =A0 =A0 =A0 > > > --------------------------------------- =A0 =A0 =A0 =A0 > > Posted throughhttp://www.FPGARelated.com Video acquisition devices usually use DMA to store the video in the host memory. Reading the video data from the video acquisition board as a PCI slave is much slower. It also uses CPU time as well as the PCI bus bandwith. Whether or not you use DMA, you will probably need a RAM attached to the FPGA as a frame buffer. This is due to the nature of PCI in that another bus master may hog the bus indefinitely, or long enough to overflow any internal FIFO buffering the video data to the DMA. Regards, GaborArticle: 149878
> What are the pros and cons of implementing the FPGA as a PCI master > versus as a PCI target? The vast majority of (all?) PCI 'hosts' can't burst target reads. This means if you want to make the most of the PCI bandwidth you'll have to implement a PCI master core in the FPGA and use this to DMA data into the host memory. Nial.Article: 149879
Thanks for the answers so far. I do plan on using an an external RAM to buffer the video data. I'm still confused about doing the DMA in the host PC versus on the FPGA. So is it even possible to use the host CPU's dma controller to fetch one frame at a time using a whole bunch of consecutive PCI reads? Why would this hold up the cpu and why is this so much slower than doing it the other way round? On Nov 30, 11:07=A0am, "Nial Stewart" <nial*REMOVE_TH...@nialstewartdevelopments.co.uk> wrote: > > What are the pros and cons of implementing the FPGA as a PCI master > > versus as a PCI target? > > The vast majority of (all?) PCI 'hosts' can't burst target reads. > > This means if you want to make the most of the PCI bandwidth you'll have > to implement a PCI master core in the FPGA and use this to DMA data > into the host memory. > > Nial.Article: 149880
On 11/30/2010 07:05 AM, Gravis wrote: > I have a FPGA project and it needs to interface with my PC. The problem > I've run into is finding a fast form of communication with very low > latency. I've come asking for advice and possible solution. > > I need a link that can transfer 1KB 1200 times every second, not just 1.2MB > a second because the input is dependent on the output. The latency issue > makes USB impossible and a normal serial port doesnt have the bandwidth. > My initial inclination was to use a IEEE 1394 connection but the interface > driver ICs are both expensive and too small to solder. I've looked for an > HDL implementation of the driver but I cannot find one. Does anyone know > of a way to interface with a PC that can be or has been implemented on a > FPGA or has a low component count? PCI -- see if your favored FPGA vendor has a PCI development board, plug it into your computer, and go (or at least start thrashing with the PCI interface). SATA -- "But that's for hard drives!". Yes, but apparently at the physical level it's also a good, fairly real-time way to move data fast. Circuit Cellar magazine had an article on using it (and ATA) for just this application. Have you looked into USB in isochronous mode? I don't know if buffering would get in your way or not, but it's a thought. Or ditch the PC, and use a processor on the FPGA, or next to it, that doesn't have the latency issues of a PC. -- Tim Wescott Wescott Design Services http://www.wescottdesign.com Do you need to implement control loops in software? "Applied Control Theory for Embedded Systems" was written for you. See details at http://www.wescottdesign.com/actfes/actfes.htmlArticle: 149881
On Nov 30, 8:31=A0am, rickman <gnu...@gmail.com> wrote: > On Nov 30, 8:18=A0am, Martin Thompson <martin.j.thomp...@trw.com> wrote: > > rickman <gnu...@gmail.com> writes: > > > On Nov 29, 4:38 am, Martin Thompson <martin.j.thomp...@trw.com> wrote= : > > > but I don't recall ever taking a single process and > > > promoting it to an entity. =A0When the tool does this, does it also a= dd > > > the required signal declarations? =A0How does it know which signals n= eed > > > to be in the ports list and which need to be declared as local > > > signals? > > > Things that go "into" the process or "out of" the process are entity > > ports. =A0There's no need for local signals, as it's just one process > > you're pushing. > > Exactly. =A0I nearly always have some concurrent logic that goes with > the process. I'm curious about the case where a process is the only reader and writer of a signal (obviously declared outside the process). Does Sigasi know that it does not need to create an inout port for that signal when it promotes the process to an entity? Does Sigasi only look at the process, and not the rest of the architecture to which it belongs, when deciding which signals need promoting to ports? I use local variables for this case, but many others use a signal because they prefer the postponed update semantics of signals vs variables. AndyArticle: 149882
mksuth <mksutherland5@gmail.com> wrote: >I am building an FPGA data acquisition board which will interface with >the PC over the PCI bus at 33Mhz. The fpga is going to be responsible >for acquiring data from peripheral devices and passing this to the >CPU. The data includes two separate video channels as well as some >sensor readings. > >What are the pros and cons of implementing the FPGA as a PCI master >versus as a PCI target? > >I will need to use DMA to do the actual transfers. What are the pros >and cons of doing the DMA on the PC side versus on the FPGA side? > >Can anyone give me a high level overview of how DMA would work with >PCI as a master versus a target? With PCI there is no such thing as DMA. What PCI can do is transfer data between devices. If you want to transfer blocks of data (burst) then your card must be capable of becoming a master. Most if not all computers cannot initiate burst transfers. -- Failure does not prove something is impossible, failure simply indicates you are not using the right tools... nico@nctdevpuntnl (punt=.) --------------------------------------------------------------Article: 149883
Andy wrote:
> On Nov 30, 8:31 am, rickman <gnu...@gmail.com> wrote:
>> On Nov 30, 8:18 am, Martin Thompson <martin.j.thomp...@trw.com> wrote:
>>> rickman <gnu...@gmail.com> writes:
>>>> On Nov 29, 4:38 am, Martin Thompson <martin.j.thomp...@trw.com> wrote:
>>>> but I don't recall ever taking a single process and
>>>> promoting it to an entity. When the tool does this, does it also add
>>>> the required signal declarations? How does it know which signals need
>>>> to be in the ports list and which need to be declared as local
>>>> signals?
>>> Things that go "into" the process or "out of" the process are entity
>>> ports. There's no need for local signals, as it's just one process
>>> you're pushing.
>> Exactly. I nearly always have some concurrent logic that goes with
>> the process.
>
> I'm curious about the case where a process is the only reader and
> writer of a signal (obviously declared outside the process). Does
> Sigasi know that it does not need to create an inout port for that
> signal when it promotes the process to an entity?
It sure does.
> Does Sigasi only
> look at the process, and not the rest of the architecture to which it
> belongs, when deciding which signals need promoting to ports?
It looks at the complete picture, because it understands the code as a
complete design.
Jan
--
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Python as a HDL: http://www.myhdl.org
VHDL development, the modern way: http://www.sigasi.com
Analog design automation: http://www.mephisto-da.com
World-class digital design: http://www.easics.com
Article: 149884On Nov 29, 9:54=A0pm, rickman <gnu...@gmail.com> wrote: > I'm not sure what is wrong here. I have a design that I have used in > the past and has worked ok. I am making modifications to it and my Hi- > Z outputs are being grounded. This creates some problems during > operation. The VHDL code is like this... > > TMS_B1 <=3D 'Z'; > > I just want this output to be Hi-Z for this design so that the pin > output is not driven (which clobbers these signals from other > sources). The lines for this output in the preference file are... > > LOCATE COMP "TMS_B1" SITE "36" ; > IOBUF PORT "TMS_B1" IO_TYPE=3DLVCMOS33 PULLMODE=3DKEEPER DRIVE=3D8 > SLEWRATE=3DSLOW ; > > When I load the design into the part, the output is always low and > checking the design in Epic, I see the tri-state driver has a 0 on the > input and a 0 on the enable. I believe the 0 on the enable turns on > the output driver because that is how the outputs are configured. > > I also looked at the Technology View in Synplify and I find TMS_B1 is > driven by a OB with a 0 on it's input. > > Is this a bug or is there something wrong with the way I am doing > this? I made a lot of changes to the overall design before I > discovered this bug so I'm not certain that the preference file lines > have not been changed since this was working, but I don't see how they > can be causing this problem. > > Rick Rick, Two suggestions: - try to use the syn_keep attribute in Synplify for the TMS_B1 net - remove the keeper option in the constraint (set PULLMODE =3D NONE, just for verification purposes) If nothing will change, could you let me know the SW version and the device you're using? Alex Lattice FAE (writing from home; just trying to help out :^)Article: 149885
>The fpga board will mate with a single board PC which only has a PCI >interface (actually it is a PC/104+ stackable interface). > Hey, i am working on a project similar to yours. I will be using a PC/104+ and a custom doughter card with a FPGA too. For now i am working with a board called raggedstone1 from Enterpoint. It is a PCI card with an FPGA but for standard computers. Its works for me becouse i dont got the PC/104+ on my hands right now but the PCI bus is the same. I am trying to work with OpenCOres PCI Bridge becouse it can Master the Bus so you can send and receive Bursts of packages. But i am having some problems to understand how to make it work. I hope i got some results until the end of the week (as i am working on other problems too). To help take a look at this site: http://sourceforge.net/projects/pcibridgedriver/ A guy developed a driver for linux (but it got some porblems i am trying to fix) and a "simple" guide to make use of the bridge. If you want we can exchange information to make this work faster. If you are interested my e-mail is luisf.rossIGNORETHIS@gmail.com. --------------------------------------- Posted through http://www.FPGARelated.comArticle: 149886
On Nov 30, 2:22 pm, Alex <engin...@gmail.com> wrote: > On Nov 29, 9:54 pm, rickman <gnu...@gmail.com> wrote: > > > I'm not sure what is wrong here. I have a design that I have used in > > the past and has worked ok. I am making modifications to it and my Hi- > > Z outputs are being grounded. This creates some problems during > > operation. The VHDL code is like this... > > > TMS_B1 <= 'Z'; > > > I just want this output to be Hi-Z for this design so that the pin > > output is not driven (which clobbers these signals from other > > sources). The lines for this output in the preference file are... > > > LOCATE COMP "TMS_B1" SITE "36" ; > > IOBUF PORT "TMS_B1" IO_TYPE=LVCMOS33 PULLMODE=KEEPER DRIVE=8 > > SLEWRATE=SLOW ; > > > When I load the design into the part, the output is always low and > > checking the design in Epic, I see the tri-state driver has a 0 on the > > input and a 0 on the enable. I believe the 0 on the enable turns on > > the output driver because that is how the outputs are configured. > > > I also looked at the Technology View in Synplify and I find TMS_B1 is > > driven by a OB with a 0 on it's input. > > > Is this a bug or is there something wrong with the way I am doing > > this? I made a lot of changes to the overall design before I > > discovered this bug so I'm not certain that the preference file lines > > have not been changed since this was working, but I don't see how they > > can be causing this problem. > > > Rick > > Rick, > > Two suggestions: > - try to use the syn_keep attribute in Synplify for the TMS_B1 net > - remove the keeper option in the constraint (set PULLMODE = NONE, > just for verification purposes) > > If nothing will change, could you let me know the SW version and the > device you're using? > > Alex > > Lattice FAE > (writing from home; just trying to help out :^) Hi Alex, thanks for the response. I haven't bothered my local FAE with this yet. I thought I'd give the other channels a shot first. FYI, I posted this to the Lattice forums under ispLever/Synplify. I posted a second time with the additional info that you are now asking for. I already tried the PULLMODE=NONE with another signal driving an LED and that didn't work. I haven't tried the syn_keep attribute since it is not removing the signal really. It is just treating it the wrong way. There are other pins which are not assigned at all and they get the same connection to '0'. Unused inputs have no configuration in Epic. I was once told, IIRC, that the default action for outputs not assigned is to ground them so they can be used as additional ground connections. But I'm not even sure that was Lattice software, it may have been Altera. I have no idea if this is relevant or not. I tried the syn_keep attribute on the output signal, TMS_B1 and got a warning: @W: CD134 :"C:\arius\boards\irig-b-testbed\fpga\MS- DCARD_Test_FPGA.vhd":289:24:289:29|No such identifier, tms_b1, of proper type in current declarative region I think it is telling me this attribute does not apply to outputs! My second post in the forums with the software info is below. I am still not clear on exactly what I can get in the way of updates to the software. This is a paid for copy of ispLever, not the starter version. But I never renewed the maintenance. I can get a license renewal each year when the license file runs out, but I don't know if that just lets me keep using the software or if I can get any bug fixes... such as this. I know the tools compiled this code correctly at one time. I would have never been able to program my boards on the test fixture if it didn't work. I just need to figure out if I broke it or an update that I last obtained did something bad. I find it hard to believe that something so fundamental was broken in a software update... Just to mention this again, looking at the technology view in Synplify, it clearly shows an output block (OB) with a '0' on the input and the output driving TMS_B1. So I guess this is really a Synplify issue, no? Rick ***************************************************** I see I failed to give any details of the software I am using. Also, I read the tool output carefully and found that it tells me it is tying the enable of the tri-state driver to ground. I'm actually seeing this on all six high impedance outputs I need. @W: MO111 :"c:\arius\boards\irig-b-testbed\fpga\ms- dcard_test_fpga.vhd":294:12:294:14|tristate driver TMS_B2_1 on net TMS_B2_1 has its enable tied to GND (module MS_Test) The target chip is LXFP3C-3T100C ispLEVER Service Pack SP7.2.02.21.23.09 Date: 6-23-2009 Time: 13:16:02 ispLEVER Service Pack SP7.2.01.18.08.09 Date: 4-9-2009 Time: 10:23:05 ispLEVER Production Build 7.2.00.41.49.08 Date: 4-8-2009 Time: 23:50:54 Synplify Pro for Lattice 9.6L1, Build 069R, Built Nov 3 2008 Synplicity VHDL Compiler, version 1.0, Build 020R, built Nov 5 2008 Synplicity Lattice ORCA FPGA Technology Mapper, Version 9.4.2, Build 061R, Built Nov 25 2008 Synplicity Lattice FPGA Technology Mapper, Version 9.4.2, Build 054R, Built Nov 14 2008 10:11:08Article: 149887
On Nov 30, 2:22=A0pm, Alex <engin...@gmail.com> wrote: > On Nov 29, 9:54=A0pm, rickman <gnu...@gmail.com> wrote: > > > > > I'm not sure what is wrong here. I have a design that I have used in > > the past and has worked ok. I am making modifications to it and my Hi- > > Z outputs are being grounded. This creates some problems during > > operation. The VHDL code is like this... > > > TMS_B1 <=3D 'Z'; > > > I just want this output to be Hi-Z for this design so that the pin > > output is not driven (which clobbers these signals from other > > sources). The lines for this output in the preference file are... > > > LOCATE COMP "TMS_B1" SITE "36" ; > > IOBUF PORT "TMS_B1" IO_TYPE=3DLVCMOS33 PULLMODE=3DKEEPER DRIVE=3D8 > > SLEWRATE=3DSLOW ; > > > When I load the design into the part, the output is always low and > > checking the design in Epic, I see the tri-state driver has a 0 on the > > input and a 0 on the enable. I believe the 0 on the enable turns on > > the output driver because that is how the outputs are configured. > > > I also looked at the Technology View in Synplify and I find TMS_B1 is > > driven by a OB with a 0 on it's input. > > > Is this a bug or is there something wrong with the way I am doing > > this? I made a lot of changes to the overall design before I > > discovered this bug so I'm not certain that the preference file lines > > have not been changed since this was working, but I don't see how they > > can be causing this problem. > > > Rick > > Rick, > > Two suggestions: > - try to use the syn_keep attribute in Synplify for the TMS_B1 net > - remove the keeper option in the constraint (set PULLMODE =3D NONE, > just for verification purposes) > > If nothing will change, could you let me know the SW version and the > device you're using? > > Alex > > Lattice FAE > (writing from home; just trying to help out :^) I'm not sure what to make of this. I tried looking at the results again with syn_keep applied and it *did* affect the output. But now it uses a Hi-Z output WITHOUT the syn_keep attribute!!! I changed nothing else. I did not change the KEEPER setting in the lpf file. I hate when things don't work, but I hate worse when they start working and I don't know why! Clearly I can't say I was doing everything correctly, but I have no idea what changed either. The strange part is I still get warnings from Synplicity about tying the TMS_B1 output enable to ground! @W: MO111 :"c:\arius\boards\irig-b-testbed\fpga\ms- dcard_test_fpga.vhd":295:12:295:14|tristate driver TMS_B1_1 on net TMS_B1_1 has its enable tied to GND (module MS_Test) as well as @W: MO111 :"c:\arius\boards\irig-b-testbed\fpga\ms- dcard_test_fpga.vhd":42:1:42:6|tristate driver TMS_B1_obuft.un1[0] on net TMS_B1 has its enable tied to GND (module MS_Test) in addition to @W: CD134 :"C:\arius\boards\irig-b-testbed\fpga\MS- DCARD_Test_FPGA.vhd":289:24:289:29|No such identifier, tms_b1, of proper type in current declarative region I haven't a clue about this. Worse, every time I generate a new bit file, I'll have to check the design in Epic to make sure these outputs are truly tri-stated. :-( RickArticle: 149888
On Nov 30, 9:58 am, Gabor <ga...@alacron.com> wrote: > On Nov 30, 8:46 am, rickman <gnu...@gmail.com> wrote: > > > > > On Nov 30, 2:35 am, Newman <newman5...@yahoo.com> wrote: > > > > On Nov 29, 11:54 pm, rickman <gnu...@gmail.com> wrote: > > > > > I'm not sure what is wrong here. I have a design that I have used in > > > > the past and has worked ok. I am making modifications to it and my Hi- > > > > Z outputs are being grounded. This creates some problems during > > > > operation. The VHDL code is like this... > > > > > TMS_B1 <= 'Z'; > > > > > I just want this output to be Hi-Z for this design so that the pin > > > > output is not driven (which clobbers these signals from other > > > > sources). The lines for this output in the preference file are... > > > > > LOCATE COMP "TMS_B1" SITE "36" ; > > > > IOBUF PORT "TMS_B1" IO_TYPE=LVCMOS33 PULLMODE=KEEPER DRIVE=8 > > > > SLEWRATE=SLOW ; > > > > > When I load the design into the part, the output is always low and > > > > checking the design in Epic, I see the tri-state driver has a 0 on the > > > > input and a 0 on the enable. I believe the 0 on the enable turns on > > > > the output driver because that is how the outputs are configured. > > > > > I also looked at the Technology View in Synplify and I find TMS_B1 is > > > > driven by a OB with a 0 on it's input. > > > > > Is this a bug or is there something wrong with the way I am doing > > > > this? I made a lot of changes to the overall design before I > > > > discovered this bug so I'm not certain that the preference file lines > > > > have not been changed since this was working, but I don't see how they > > > > can be causing this problem. > > > > > Rick > > > > Rick, > > > I suppose you have already convinced yourself that it is not the > > > buskeeper circuit driving the line low. > > > > Bus Maintenance Circuit > > > Each pad has a weak pull-up, weak pull-down and weak buskeeper > > > capability. The pull-up and pull-down settings > > > offer a fixed characteristic, which is useful in creating wired logic > > > such as wired ORs. However, current can be > > > slightly higher than other options, depending on the signal state. The > > > bus-keeper option latches the signal in the > > > last driven state, holding it at a valid level with minimal power > > > dissipation. Users can also choose to turn off the bus > > > maintenance circuitry, minimizing power dissipation and input leakage. > > > Note that in this case, it is important to > > > ensure that inputs are driven to a known state to avoid unnecessary > > > power dissipation in the input buffer. > > > Thanks for the suggestion, but yes, I eliminated that by looking at > > the I/O block settings in Epic, the layout editor. I originally saw > > this problem with an LED driving pin. I set it for hi-z and it was > > driving the LED on hard. A bus keeper wouldn't drive that hard. > > Besides, this pin is driving two LEDs, one up and one down. Hi-z is > > the only state where neither LED is on. When I use logic to select > > the three states, 1, 0, Z; then the hi-z state is enabled > > appropriately. > > > I can always work around this by controlling it from some signal such > > as reset so that it is always hi-z after the FPGA is up. It is odd > > that this worked just fine before and now screws up. I haven't > > updated any of the development software that I know of, but I haven't > > messed with this design since 2008, so there's been a lot of water > > under the dam since then. If it is a tool problem, I may not get an > > update. My maintenance ran out long ago and this is a paid for copy. > > I'd hate to have to shell out a kilobuck to get a bug fix so I can > > continue using the software that I already paid for. > > > Rick > > This looks remarkably like something I remember from older Xilinx > projects where assigning an output to 'Z' effectively removed it from > the > design. (the output isn't "driven" so get rid of it) Then the > default > action for the backend tools is to take any undriven outputs and > ground them (you must have forgotten to assign a value to this). > > What would happen if you changed the output so it is only tristate > under some condition? You could pick some condition that you > know is always true, but the synthesizer can't guess, or make the > output briefly drive (high or low) as the design comes out of reset. > > Does your project perhaps have a setting or unused IOB's to > be "virtual grounds"? > > All I can think of... > > -- Gabor Hi Gabor. I also have outputs driving pairs of LEDs that are conditional and can be either '0', '1' or 'Z'. They work just fine. In fact, I first saw this on LED drive outputs that I drove with a 'Z'. The red LEDs came on which means it was pulled hard to ground. I turned off the buskeeper mode and it still drove the output hard to ground. That was when I first looked at the design in Epic and saw the tri-state control driven to a fixed '0' instead of a fixed '1', like it is now! If I hadn't see this before, it would have been ten times harder to figure out what was keeping my programming cable from working with by target boards! These JTAG signals are also connected to the test fixture FPGA in case I get to the point where I want the FPGA to program the target boards instead of using the Lattice software. Oddly enough, Lattice cautions you against using the USB cable for production programming. I guess this is just a CYA thing in case it doesn't work correctly and you ship 10,000 boards that aren't programmed right... "don't come back to us"! I had considered controlling the tri-states with some signal that would not conflict with an external driver of the JTAG signals, such as the GSR or maybe a switch input. But the issue seems to have resolved itself. I'm not sure I will ever know what was wrong unless it returns. I know the preference file gets rewritten each time I run the tool, but I can't say the file actually changes. I haven no idea why it has to write the file back out each time. The only thing it seems to change is when I put a title block at the head of the file, the tools keep writing the line, "COMMERCIAL;" just in front of it. No matter where I put this line in the file, it gets moved to the first line. If nothing else, it helps to have others make suggestions. It can be easier to figure things out when you have to explain something and think about other's comments. Thanks. RickArticle: 149889
I=92ve made available a web application that can parse different Xilinx reports: http://outputlogic.com/reportxplorer To get started with the app just click on the =93Load Samples=94 button on the left side of the main screen. For more information read a blog post: http://outputlogic.com/?p=3D637 A more complete user guide is here: http://outputlogic.com/reportxplorer/do= cs/user_guide.pdf The application might be useful for FPGA designers that spend a lot of time reading and analyzing build reports. Me and my team have been developing and actively using it for quite some time. Any feedback about usability, missing features, and bugs is welcome. Thanks, EvgeniArticle: 149890
On Nov 30, 7:56=A0pm, rickman <gnu...@gmail.com> wrote: > On Nov 30, 2:22=A0pm, Alex <engin...@gmail.com> wrote: > > > > > > > On Nov 29, 9:54=A0pm, rickman <gnu...@gmail.com> wrote: > > > > I'm not sure what is wrong here. I have a design that I have used in > > > the past and has worked ok. I am making modifications to it and my Hi= - > > > Z outputs are being grounded. This creates some problems during > > > operation. The VHDL code is like this... > > > > TMS_B1 <=3D 'Z'; > > > > I just want this output to be Hi-Z for this design so that the pin > > > output is not driven (which clobbers these signals from other > > > sources). The lines for this output in the preference file are... > > > > LOCATE COMP "TMS_B1" SITE "36" ; > > > IOBUF PORT "TMS_B1" IO_TYPE=3DLVCMOS33 PULLMODE=3DKEEPER DRIVE=3D8 > > > SLEWRATE=3DSLOW ; > > > > When I load the design into the part, the output is always low and > > > checking the design in Epic, I see the tri-state driver has a 0 on th= e > > > input and a 0 on the enable. I believe the 0 on the enable turns on > > > the output driver because that is how the outputs are configured. > > > > I also looked at the Technology View in Synplify and I find TMS_B1 is > > > driven by a OB with a 0 on it's input. > > > > Is this a bug or is there something wrong with the way I am doing > > > this? I made a lot of changes to the overall design before I > > > discovered this bug so I'm not certain that the preference file lines > > > have not been changed since this was working, but I don't see how the= y > > > can be causing this problem. > > > > Rick > > > Rick, > > > Two suggestions: > > - try to use the syn_keep attribute in Synplify for the TMS_B1 net > > - remove the keeper option in the constraint (set PULLMODE =3D NONE, > > just for verification purposes) > > > If nothing will change, could you let me know the SW version and the > > device you're using? > > > Alex > > > Lattice FAE > > (writing from home; just trying to help out :^) > > I'm not sure what to make of this. =A0I tried looking at the results > again with syn_keep applied and it *did* affect the output. =A0But now > it uses a Hi-Z output WITHOUT the syn_keep attribute!!! =A0I changed > nothing else. =A0I did not change the KEEPER setting in the lpf file. > > I hate when things don't work, but I hate worse when they start > working and I don't know why! =A0Clearly I can't say I was doing > everything correctly, but I have no idea what changed either. =A0The > strange part is I still get warnings from Synplicity about tying the > TMS_B1 output enable to ground! > > @W: MO111 :"c:\arius\boards\irig-b-testbed\fpga\ms- > dcard_test_fpga.vhd":295:12:295:14|tristate driver TMS_B1_1 on net > TMS_B1_1 has its enable tied to GND (module MS_Test) > > as well as > > @W: MO111 :"c:\arius\boards\irig-b-testbed\fpga\ms- > dcard_test_fpga.vhd":42:1:42:6|tristate driver TMS_B1_obuft.un1[0] on > net TMS_B1 has its enable tied to GND (module MS_Test) > > in addition to > > @W: CD134 :"C:\arius\boards\irig-b-testbed\fpga\MS- > DCARD_Test_FPGA.vhd":289:24:289:29|No such identifier, tms_b1, of > proper type in current declarative region > > I haven't a clue about this. =A0Worse, every time I generate a new bit > file, I'll have to check the design in Epic to make sure these outputs > are truly tri-stated. =A0:-( > > Rick- Hide quoted text - > > - Show quoted text - If one can instantiate IOB primitives like you can do in Xilinx, one thing to try would be to instantiate the hi Z IOB's and manually strap the tristate enable in the code. This would seem to take the Synthesizer out of the picture. Several years ago, I had a bizarre problem with a Xilinx installation where the IT department forced me to use a network drive that was located in another state. I think the cache was not maintaining sync or something. The cause and effect relationship observed by me disappeared during that period. I started using only local design data on my machine and things got much better.Article: 149891
On Dec 1, 1:08=C2=A0am, Newman <newman5...@yahoo.com> wrote: > On Nov 30, 7:56=C2=A0pm, rickman <gnu...@gmail.com> wrote: > > > > > > > On Nov 30, 2:22=C2=A0pm, Alex <engin...@gmail.com> wrote: > > > > On Nov 29, 9:54=C2=A0pm, rickman <gnu...@gmail.com> wrote: > > > > > I'm not sure what is wrong here. I have a design that I have used i= n > > > > the past and has worked ok. I am making modifications to it and my = Hi- > > > > Z outputs are being grounded. This creates some problems during > > > > operation. The VHDL code is like this... > > > > > TMS_B1 <=3D 'Z'; > > > > > I just want this output to be Hi-Z for this design so that the pin > > > > output is not driven (which clobbers these signals from other > > > > sources). The lines for this output in the preference file are... > > > > > LOCATE COMP "TMS_B1" SITE "36" ; > > > > IOBUF PORT "TMS_B1" IO_TYPE=3DLVCMOS33 PULLMODE=3DKEEPER DRIVE=3D8 > > > > SLEWRATE=3DSLOW ; > > > > > When I load the design into the part, the output is always low and > > > > checking the design in Epic, I see the tri-state driver has a 0 on = the > > > > input and a 0 on the enable. I believe the 0 on the enable turns on > > > > the output driver because that is how the outputs are configured. > > > > > I also looked at the Technology View in Synplify and I find TMS_B1 = is > > > > driven by a OB with a 0 on it's input. > > > > > Is this a bug or is there something wrong with the way I am doing > > > > this? I made a lot of changes to the overall design before I > > > > discovered this bug so I'm not certain that the preference file lin= es > > > > have not been changed since this was working, but I don't see how t= hey > > > > can be causing this problem. > > > > > Rick > > > > Rick, > > > > Two suggestions: > > > - try to use the syn_keep attribute in Synplify for the TMS_B1 net > > > - remove the keeper option in the constraint (set PULLMODE =3D NONE, > > > just for verification purposes) > > > > If nothing will change, could you let me know the SW version and the > > > device you're using? > > > > Alex > > > > Lattice FAE > > > (writing from home; just trying to help out :^) > > > I'm not sure what to make of this. =C2=A0I tried looking at the results > > again with syn_keep applied and it *did* affect the output. =C2=A0But n= ow > > it uses a Hi-Z output WITHOUT the syn_keep attribute!!! =C2=A0I changed > > nothing else. =C2=A0I did not change the KEEPER setting in the lpf file= . > > > I hate when things don't work, but I hate worse when they start > > working and I don't know why! =C2=A0Clearly I can't say I was doing > > everything correctly, but I have no idea what changed either. =C2=A0The > > strange part is I still get warnings from Synplicity about tying the > > TMS_B1 output enable to ground! > > > @W: MO111 :"c:\arius\boards\irig-b-testbed\fpga\ms- > > dcard_test_fpga.vhd":295:12:295:14|tristate driver TMS_B1_1 on net > > TMS_B1_1 has its enable tied to GND (module MS_Test) > > > as well as > > > @W: MO111 :"c:\arius\boards\irig-b-testbed\fpga\ms- > > dcard_test_fpga.vhd":42:1:42:6|tristate driver TMS_B1_obuft.un1[0] on > > net TMS_B1 has its enable tied to GND (module MS_Test) > > > in addition to > > > @W: CD134 :"C:\arius\boards\irig-b-testbed\fpga\MS- > > DCARD_Test_FPGA.vhd":289:24:289:29|No such identifier, tms_b1, of > > proper type in current declarative region > > > I haven't a clue about this. =C2=A0Worse, every time I generate a new b= it > > file, I'll have to check the design in Epic to make sure these outputs > > are truly tri-stated. =C2=A0:-( > > > Rick- Hide quoted text - > > > - Show quoted text - > > If one can instantiate IOB primitives like you can do in Xilinx, one > thing to try would be to instantiate the hi Z IOB's and manually strap > the tristate enable in the code. =C2=A0This would seem to take the > Synthesizer out of the picture. > > Several years ago, I had a bizarre problem with a Xilinx installation > where the IT department forced me to use a network drive that was > located in another state. =C2=A0I think the cache was not maintaining syn= c > or something. The cause and effect relationship observed by me > disappeared during that period. =C2=A0I started using only local design > data on my machine and things got much better.- Hide quoted text - > > - Show quoted text - Sounds like a hassle - (automatic I/O insertion by synthesis must be disabled). I/O Buffer Insertion You can use two ways to insert I/O buffers or pads into the EDIF netlist produced by logic synthesis: =F4=80=82=8B Insert them by default during synthesis. =F4=80=82=8B Instantiate I/O buffers (automatic I/O insertion by synthesis = must be disabled). To minimize the amount of code required to design with I/O buffers, Lattice Semiconductor provides a Verilog HDL and a VHDL synthesis header library file for each major FPGA device family. Refer to the =E2=80=9CLattice Synthesis Header Libraries=E2=80=9D topic in the ispLEVER online Help for details. http://www.latticesemi.com/lit/docs/manuals/fpga_design_guide.pdfArticle: 149892
> On 11/30/2010 07:05 AM, Gravis wrote: > I have a FPGA project and it needs to interface with my PC. =A0The proble= m > I've run into is finding a fast form of communication with very low > latency. =A0I've come asking for advice and possible solution. Interesting question, I will jump on the bandwagon and ask the same thing too. I'm interested in low latency between an FPGA and user space RAM on a PC too. On Nov 30, 5:17=A0pm, Tim Wescott <t...@seemywebsite.com> wrote: > PCI -- see if your favored FPGA vendor has a PCI development board, plug > it into your computer, and go (or at least start thrashing with the PCI > interface). > > SATA -- "But that's for hard drives!". =A0Yes, but apparently at the > physical level it's also a good, fairly real-time way to move data fast. > =A0 Circuit Cellar magazine had an article on using it (and ATA) for just > this application. Tim, does using SATA not imply that PCI is also used? That is FPGA -> SATA -> PCI. PCs have their SATA controllers on a chipset which makes them available on the PCI bus. For example if I do 'lspci' on this one I get: 00:1f.2 SATA controller: Intel Corporation 5 Series/3400 Series Chipset 6 port SATA AHCI Controller (rev 06) So SATA must include the latency of PCI plus its own? Is SATA easier to work with than PCI on an FPGA? There are some high end FPGA cards now that plug into CPU sockets, on Intel QuickPath or Hypertransport. Would these be lower latency than PCI? I'm interested in low latency like the OP, but I'm talking single digit or sub-microsecond. Does anyone know approximately what the latency of using PCI is, to send an interrupt and have the 1KB of data the OP is using transferred into RAM? RupertArticle: 149893
On Dec 1, 4:57=A0pm, "rupertlssm...@googlemail.com" <rupertlssm...@googlemail.com> wrote: > > On 11/30/2010 07:05 AM, Gravis wrote: > > I have a FPGA project and it needs to interface with my PC. =A0The prob= lem > > I've run into is finding a fast form of communication with very low > > latency. =A0I've come asking for advice and possible solution. > > Interesting question, I will jump on the bandwagon and ask the same > thing too. I'm interested in low latency between an FPGA and user > space RAM on a PC too. > > On Nov 30, 5:17=A0pm, Tim Wescott <t...@seemywebsite.com> wrote: > > > PCI -- see if your favored FPGA vendor has a PCI development board, plu= g > > it into your computer, and go (or at least start thrashing with the PCI > > interface). > > > SATA -- "But that's for hard drives!". =A0Yes, but apparently at the > > physical level it's also a good, fairly real-time way to move data fast= . > > =A0 Circuit Cellar magazine had an article on using it (and ATA) for ju= st > > this application. > > Tim, does using SATA not imply that PCI is also used? That is FPGA -> > SATA -> PCI. PCs have their SATA controllers on a chipset which makes > them available on the PCI bus. For example if I do 'lspci' on this one > I get: > > 00:1f.2 SATA controller: Intel Corporation 5 Series/3400 Series > Chipset 6 port SATA AHCI Controller (rev 06) > > So SATA must include the latency of PCI plus its own? Is SATA easier > to work with than PCI on an FPGA? > > There are some high end FPGA cards now that plug into CPU sockets, on > Intel QuickPath or Hypertransport. Would these be lower latency than > PCI? I'm interested in low latency like the OP, but I'm talking single > digit or sub-microsecond. > > Does anyone know approximately what the latency of using PCI is, to > send an interrupt and have the 1KB of data the OP is using transferred > into RAM? > > Rupert Hi all, we offer SATA Device IP Core for FPGAs. The FPGA side is fully integrated, on-chip transceivers as SATA PHY. SoC side is very flexible, with traditional CPU interface and streaming interface options. I am not sure what kind of latency and bandwidth you are looking for, but SATA is pretty reliable and offers 300 MB/sec for Gen 2 and 600 MB/s for Gen 3. Latency will depend on the host PC and it's architecture. Typically PCs have pretty fast internal SATA interfaces ... Best Regards, rudiArticle: 149894
rickman <gnuarm@gmail.com> writes: > On Nov 30, 8:18 am, Martin Thompson <martin.j.thomp...@trw.com> wrote: >> rickman <gnu...@gmail.com> writes: >> > On Nov 29, 4:38 am, Martin Thompson <martin.j.thomp...@trw.com> wrote: >> Yes, it changes the entity delaaration, uses of that port inside the >> entity and the port mapping of the instantiation(s) of the entity. >> >> This is better than a global (ie multi-file) replace because when you >> change "write" on one entity to "write_n" you don't want every entity >> with a "write" pin changing! And heaven help you changing rd to wr - >> hope the characters 'rd' don't appear in any other pins anywhere else >> (like the "one_third" pin of your "divide_by_three" entity ;) > > That's not a big deal. My editor, and I suspect many others, has a > check box on the search that says "only full word match" so that > write_n won't match a write search. No, my point was if you have "write" on another entity you don;t want that one changing as well. >> > I learned a long time ago that before I spend the time to learn a >> > tool, I need to have a pretty good reason to make the investment. So >> > far I haven't see such a reason to learn the Sigasi tool. >> >> Forgive me, but if you're still using Codewright (unless it has >> changed immeasureably since I migrated from it to Emacsin the CW5.x >> days) I'd be amazed if Sigasi wouldn't help. >> >> How much time do you spend copying "columns" from entities and >> changing : to => in port maps to instance a component? That used to >> drive me demented in CW. > > That's the part I have regex lines to handle. I have to tweek the > last line of the port list so it has a terminator, apply the regex, > tweek the terminator back and adjust the column alignments (manually, > I am a little OCD about this part). All stuff you'd rather not do, right? > Then That's the key word :) After doing some stuff... > I have everything perfectly formatted and even the comments within > the port list are transferred. After a dozen or so passes with the > regex it was tweeked enough to cover all the weird cases such as > including "_" in the names, etc. I have one regex to generate the > instantiation port map and another to generate signal declarations. OK, you've gotten further configurating CW than I ever did :) > > I may spend a little more time with it so it will write the code for > the entity body given a customer's description of the problem. ;^) > Good plan, let us know when you've got that sorted, we could all use it :) > >> >> (BTW, although I may sound like a salesman, I have no connection with >> >> Sigasi, other than being impressed with the demo :) I still haven't >> >> quite been torn away from Emacs vhdl-mode though... even though it's >> >> missing the two features above! >> >> > It has been very seldom that I have seen a tool which I decided I >> > needed enough to drop an old tool and pick up the new. >> >> Me too. Migrating from CW to Emacs was the last time I recall doing >> it. And that was a *serious* learning curve, but still worth it. >> Sigasi is way easier IMHO. > > I only have two problems with Sigasi. One is spending time with it to > be convinced that it is better in some so far, unidentified way. Well, with respect, I've indentified a number of ways it's better than raw Codewright. The fact that you've overcome those was unknown to me. I see below that I've also identified some things you *would* like... > The other is that it is commercial software with an up front cost > and I assume a recurring cost. Being a small shop I don't often pay > for tools unless I am absolutely convinced I need them. Notice I > said "need", not "would like" or "nice to have" or even "would be > more productive if". When I am working the VHDL I bang code all day > long. But I don't do it all the time. > I also spend time designing the boards, writing test code, specs, > docs and even conversing with customers... oh yeah, and that > slightly important part, looking for customers. This I also understand - I'd like to use some of the c-to-gates tools, but I don't want to pay for a whole year's worth of flat-out license when I'd use it maybe 25% of the year. Emacs also suits me nicely license-wise! > I'm not inclined to spend a kilobuck on something that will give me > a minor improvement in what I do maybe 10% of the time. Then on top > of it all, a tool that requires support from a company is already a > rung lower on the ladder Sorry, which ladder are you talking about? > than a tool that is either static because it is already > unsupported (Codewright and Eudora) or open source and supported by > an active community. The most useful tools I have are (other than > the FPGA tools that I have no choice with) are one of those two > categories. The biggest bane to my existence, tool- wise, is the > licensed tools I have to keep running, but only weekdays 9-5. I am > having a problem with the Lattice tools right now that I am having > to go through support (or around actually) to resolve. > Agreed - licensed tools can cause a lot of pain! <about autocompletion> > Is this the way it works in Sigasi with signal names? If you are > typing a signal name as the first thing on a line, does it add the > assignment operator? What happens the first time you type an > assignment to a signal or variable? Does it add a declaration for the > name? IIRC you start typing the first few chars and hit ctrl-space, and it gives you a drop-down of potential completions. >> Some Other things it does (full list is athttp://www.sigasi.com/featurelist): >> * Autocomplete templates for "if", "process", and the rest. > Nice, but not a big deal, for me anyway. Ahh, I'd thought you'd said automating boilerplate code was on your list - sorry. > >> * Line alignment (so all your : and <= and => line up nicely) > That would be nice. > Much more than "nice" to me - esp. if others see your code - nothing like bad formatting to make people wonder whether the logic is similarly wiggly! <snip> > I'll be finished with my VHDL coding in another week or two and won't > want to spend time with a VHDL tool. I am going to look into a design > using a multiprocessor chip that is micro power or nano power or pico > power, what ever it is being called these days. Idle state is 100 > micro watts per processor with 144 processors on the chip. Running > full out they use 4.5 mW at over 500 MIPS! Sounds fun - that sounds like a greenarray? Cheers, Martin -- martin.j.thompson@trw.com TRW Conekt - Consultancy in Engineering, Knowledge and Technology http://www.conekt.co.uk/capabilities/39-electronic-hardwareArticle: 149895
On Dec 1, 8:29=A0am, Martin Thompson <martin.j.thomp...@trw.com> wrote: > rickman <gnu...@gmail.com> writes: > > On Nov 30, 8:18 am, Martin Thompson <martin.j.thomp...@trw.com> wrote: > > >> This is better than a global (ie multi-file) replace because when you > >> change "write" on one entity to "write_n" you don't want every entity > >> with a "write" pin changing! And heaven help you changing rd to wr - > >> hope the characters 'rd' don't appear in any other pins anywhere else > >> (like the "one_third" pin of your "divide_by_three" entity ;) > > > That's not a big deal. =A0My editor, and I suspect many others, has a > > check box on the search that says "only full word match" so that > > write_n won't match a write search. > > No, my point was if you have "write" on another entity you don;t want > that one changing as well. Yes, if "only full word match" is used, then "write_n" won't match a "write" search and replace so only "write" will change. > >> How much time do you spend copying "columns" from entities and > >> changing : to =3D> in port maps to instance a component? That used to > >> drive me demented in CW. > > > That's the part I have regex lines to handle. =A0I have to tweek the > > last line of the port list so it has a terminator, apply the regex, > > tweek the terminator back and adjust the column alignments (manually, > > I am a little OCD about this part). =A0 > > All stuff you'd rather not do, right? My point is it's not much of a problem. I can live with a regex replace. It is not on the list of things I want to switch editors to prevent doing. > > Then > > That's the key word :) =A0After doing some stuff... > > > I have everything perfectly formatted and even the comments within > > the port list are transferred. =A0After a dozen or so passes with the > > regex it was tweeked enough to cover all the weird cases such as > > including "_" in the names, etc. =A0I have one regex to generate the > > instantiation port map and another to generate signal declarations. > > OK, you've gotten further configurating CW than I ever did :) I'd be happy to share my regex strings ;-) The limitation of CW is that you can't hard code these replace strings into a button... that I have been able to figure out. There are some real programming capabilities, but I haven't learned it all and the product is no longer supported or even sold I believe. > > I may spend a little more time with it so it will write the code for > > the entity body given a customer's description of the problem. =A0;^) > > Good plan, let us know when you've got that sorted, we could all use > it :) But you'd have to use CW! Or if I get a little more familiarity with the tool, I could code it in Win32Forth... ;^) > >> > It has been very seldom that I have seen a tool which I decided I > >> > needed enough to drop an old tool and pick up the new. > > >> Me too. Migrating from CW to Emacs was the last time I recall doing > >> it. And that was a *serious* learning curve, but still worth it. > >> Sigasi is way easier IMHO. > > > I only have two problems with Sigasi. =A0One is spending time with it t= o > > be convinced that it is better in some so far, unidentified way. =A0 > > Well, with respect, I've indentified a number of ways it's better than > raw Codewright. =A0The fact that you've overcome those was unknown to > me. =A0I see below that I've also identified some things you *would* like= ... > > > The other is that it is commercial software with an up front cost > > and I assume a recurring cost. =A0Being a small shop I don't often pay > > for tools unless I am absolutely convinced I need them. =A0Notice I > > said "need", not "would like" or "nice to have" or even "would be > > more productive if". =A0When I am working the VHDL I bang code all day > > long. =A0But I don't do it all the time. > > I also spend time designing the boards, writing test code, specs, > > docs and even conversing with customers... oh yeah, and that > > slightly important part, looking for customers. =A0 > > This I also understand - I'd like to use some of the c-to-gates tools, > but I don't want to pay for a whole year's worth of flat-out license > when I'd use it maybe 25% of the year. > > Emacs also suits me nicely license-wise! > > > I'm not inclined to spend a kilobuck on something that will give me > > a minor improvement in what I do maybe 10% of the time. =A0Then on top > > of it all, a tool that requires support from a company is already a > > rung lower on the ladder > > Sorry, which ladder are you talking about? Sorry, the evaluation of the tool ladder. I don't know how this tool is licensed, but I am very down on commercial tools because of the licensing issues and the seeming lack of support. That automatically puts a commercial tool below any open source tool when I am evaluating them. So the commercial tool has to be significantly better for me to want it. > > than a tool that is either static because it is already > > unsupported (Codewright and Eudora) or open source and supported by > > an active community. =A0The most useful tools I have are (other than > > the FPGA tools that I have no choice with) are one of those two > > categories. =A0The biggest bane to my existence, tool- wise, is the > > licensed tools I have to keep running, but only weekdays 9-5. =A0I am > > having a problem with the Lattice tools right now that I am having > > to go through support (or around actually) to resolve. > > Agreed - licensed tools can cause a lot of pain! > > <about autocompletion> > > > Is this the way it works in Sigasi with signal names? =A0If you are > > typing a signal name as the first thing on a line, does it add the > > assignment operator? =A0What happens the first time you type an > > assignment to a signal or variable? =A0Does it add a declaration for th= e > > name? > > IIRC you start typing the first few chars and hit ctrl-space, and it > gives you a drop-down of potential completions. And those completions include both keywords as well as your signal/ variable names? If this feature works well enough I might consider Sigasi. Especially if it could be used for other languages than just VHDL. Is the VHDL aspect hard coded? I expect it will also support Verilog, but what about generic languages? Does it have a means of setting it up for an arbitrary language like CW does? > >> Some Other things it does (full list is athttp://www.sigasi.com/featur= elist): > >> * Autocomplete templates for "if", "process", and the rest. > > Nice, but not a big deal, for me anyway. > > Ahh, I'd thought you'd said automating boilerplate code was on your > list - sorry. It is, but I guess I'm saying this is not a big enough feature to move to a new tool for. I may have some down time in the new year. Maybe I'll give the Sigasi tool a try. You are starting to convince me. But learning curves are a PITA and if I have to pay for the tool, the curve has to be short and the reward has to be big! > >> * Line alignment (so all your : and <=3D and =3D> line up nicely) > > That would be nice. > > Much more than "nice" to me - esp. if others see your code - nothing > like bad formatting to make people wonder whether the logic is > similarly wiggly! Line indentation is a bigger hassle for me. I can line up the <=3D and : parts without too much trouble. But I have to admit if you bring a number of these little features together it might be worth something. > > I'll be finished with my VHDL coding in another week or two and won't > > want to spend time with a VHDL tool. =A0I am going to look into a desig= n > > using a multiprocessor chip that is micro power or nano power or pico > > power, what ever it is being called these days. =A0Idle state is 100 > > micro watts per processor with 144 processors on the chip. =A0Running > > full out they use 4.5 mW at over 500 MIPS! =A0 > > Sounds fun - that sounds like a greenarray? Give the man a cupie doll! In the Spring they will have a 144 processor part with five ADC and DAC and have released a data sheet for the GA4 (4 processors) with no device release date. But Chuck's blog indicates they have had prototype GA4 and GA32 devices for some time. On the other hand, Chuck's blog seems to show a company that is on the low end of struggling. I have no idea if they will manage to stay solvent long enough to ship product. I am considering designing a Radio Controlled Clock using a GA4 which would run off of two AAA cells for over a year. That should be a good demo of the low power capabilities, no? Would that make you believe that the chip can be pretty low power? The interesting part is that this can be done with the GA144 nearly as easily as the GA4, you just pay more to have 143 processors sitting idle 100% of the time and 1 processor idle 95% of the time. RickArticle: 149896
> So is it even possible to use the host CPU's dma controller to fetch > one frame at a time using a whole bunch of consecutive PCI reads? Why > would this hold up the cpu and why is this so much slower than doing > it the other way round? The minimum number of clock cycles for a PCI read transaction is 5 (from memory). If you can't burst reads (which you can't from a target) then for every 32 bit word you read it takes 5 (or more) clocks. With the same overhead a burst transfer can transfer up to 128 (I think) 32 bit words, so it's _much_ more efficient. I think I managed ~ 8Mb/s using target reads, bursting you can aim for ~60Mb/s (in a system with other things on the PCI bus). You need to get hold of the PCI spec if you're going to be implementing an interface. NialArticle: 149897
> > > Does anyone know approximately what the latency of using PCI is, to > > send an interrupt and have the 1KB of data the OP is using transferred > > into RAM? > I'm a bit confused by this. Typically high bandwidth costs you a bit of latency. I.E. if you need to get 1KB across an interface you live with a relatively long setup time, after which the data moves very quickly. If you want to read or write a single word there is little setup (latency), and your access just completes. ColinArticle: 149898
On Nov 30, 4:34=A0pm, mksuth <mksutherla...@gmail.com> wrote: > Thanks for the answers so far. > > I do plan on using an an external RAM to buffer the video data. > > I'm still confused about doing the DMA in the host PC versus on the > FPGA. > > So is it even possible to use the host CPU's dma controller to fetch > one frame at a time using a whole bunch of consecutive PCI reads? Why > would this hold up the cpu and why is this so much slower than doing > it the other way round? > > On Nov 30, 11:07=A0am, "Nial Stewart" It becomes easier to understand if you think about the case when the read data is not ready. This causes the device being read to drive TRDY until its data is ready and then the burst continues. The first thing that happens is your mouse doesn't work during the transfer until perhaps the system monitor decides that the bus has locked up for too long and aborts the PCI transaction. At that point your read DMA would have to know how far it had got and then try to carry on. I appreciate that your video frame is ready to go in one hit but many applications are not. All PCI devices therefore just do not go there if at all possible. Nial has given you best case bandwidth reasons for not reading, the worst case is unacceptable sytem wide. Also it is worth learning about PCI bridges. These devices connect two or more PCI buses together but transfers only go through them when they need to. Otherwise transfers on either side can occur simultaneously. Both sides will grind to a halt during a long read through the bridge whereas a write just gets posted when the arbiter lets it. As an aside this was all sorted with PCIX but I won't go there if you are not. ColinArticle: 149899
>I think I managed ~ 8Mb/s using target reads, bursting you can aim for >~60Mb/s (in a system with other things on the PCI bus). > > >Nial > I think you intended to say 8MB/s and 60MB/s right? And Nial, have you ever developed a PCI driver to Linux? I am trying to work with the example i posted on my last post and LDD third edition, but i still got many doubts... Thabk you! --------------------------------------- Posted through http://www.FPGARelated.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