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
Steve, Interesting, thanks. AustinArticle: 118851
http://www.mmca.org/compliance/buy_spec/MMCA_System_SummaryV41.pdf page 38. Interesting. They do give alternatives, and seem to suggest the resistor is there to "protect" the host from floating signals. Austin austin wrote: > Steve, > > Interesting, thanks. > > AustinArticle: 118852
This might work: http://www.dinigroup.com/dvidc.phpArticle: 118853
On 4 May, 18:38, jetm...@hotmail.com wrote: > > We are using an FPGA (Xilinx Spartan 3) as a delevlopment platform, > > and we would like the same functionality. > > For your prototype you might want to consider my favourite solution: > > Use two I/O pins instead of one. Consider one of them as "data" pin > and route it to your peripherial. Consider the other one as "pull" > pin, and connect it with a 20K resistor to the data pin. > > For "input", put both pins in tristate. For "pullup", put the data > pin in tristate, and the pull pin in output-high (the peripherial sees > 20K pullup). Etc. > > Kind regards, > Marc We are using an off the shelf development board. Although it has space for user functionality, this will be taken by our mixed signal test chip (to form the complete system). Thanks, StevenArticle: 118854
Hi Bryan, The Spartan-3A Starter Kit, as shipped, does not include a "video pass through" demo. The main demo does allow you to MultiBoot to other designs in the flash, and there is a "configuration 4" but that design is actually Ken Chapman's parallel flash programmer design. Now, it does happen to be the case that other designs exist, but they are not (yet) posted. One of them is a video pass through design, where you connect a Digilent VDEC1 board to J17, and apply a composite video signal. The video is decoded on that expansion board, then color space converted and line doubled for output on the VGA port. In addition, there is a provision to use an attached mouse to draw on the live video (a monochrome, bitmapped overlay) and load/save overlay bitmaps into the flash. There is another derivative design, scheduled for release with the Spartan-3AN Starter Kit, that omits the video decoding, resulting in a design that is much like the Microsoft Windows "Paint" accessory... Maybe you saw the video pass through design at an XFEST event or at the Spartan-3AN press release event? Otherwise, I am not sure how you would know it exists. If you are looking for that design, please contact your local FAE or sales representative for assistance. I am not sure if/when this design will be posted. As for the derived "paint" design, that will be available when the Spartan-3AN Starter Kit is released. This specific design only works on Spartan-3AN as it leverages the internal flash for storing the bitmaps. Regarding your final question, I am not sure I understood what you are asking. I encourage you to file a support case with the Xilinx customer support team to receive official support for your product. Hope that helps, Eric "Bryan" <sfoo@xilinx.com> wrote in message news:f1end6$tf1@cnn.xsj.xilinx.com... > Hi, My name is Bryan from Xilinx Asia Pacific. I have on hand a Spartan 3A > Starter Kit . However, I was trying out Multiboot Demo Config option 4 > which is a video pass through demo that does not seem to work out though. > I hook up a camera through a composite cable to a video decoder peripheral > which is connected to the starter kit via J17 connector. In addition a LCD > monitor is also connected via VGA port to the Starter Kit. No image > appears on the monitor when config 4 was run. I thought I was supposed to > see images captured by the camera on the LCD. Can anyone help me with > this? > > Also I would like to ask is it possible to port a design within the > Spartan 3A Starter Kit PROM to another Spartan 3A Starter Kit PROM. If it > is possible, what are the steps needed to be done? > > Thank youArticle: 118855
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 austin wrote: > http://www.mmca.org/compliance/buy_spec/MMCA_System_SummaryV41.pdf > > page 38. > > Interesting. They do give alternatives, and seem to suggest the > resistor is there to "protect" the host from floating signals. In ident mode, all the drivers (and there can be multiple) are in open collector mode and together with a single pullup on the signal form a wired or. The pull-up is required to get logic-1 values on the bus without double-driving. When past the ident mode, the drivers are push-pull and know by protocol when they are supposed to tri-state themselves. Then the pull-up is supposed to be electrically "removed". I'm no EE, but I think the point is to get high-speed at the lowest possible current, because these cards tend to be in battery-powered devices. - -- Steve Williams "The woods are lovely, dark and deep. steve at icarus.com But I have promises to keep, http://www.icarus.com and lines to code before I sleep, http://www.picturel.com And lines to code before I sleep." -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFGO3iNrPt1Sc2b3ikRAjm3AJ900o7NbFbwTuP8OIOZuSxUXjm7qgCcDjpv IlmMq8b+NE2t1Dq5G3VqE80= =ZrjM -----END PGP SIGNATURE-----Article: 118856
Using ISE 8.2i I have created a top-level schematic and inside of it, wired some VHDL modules (as black boxes). I made my testbench and "added" it to the project. WHen i try to run ISE simulator (GEnerate Expected REsults or BEhavioral SImulation), ISE simply does nothing (no message, no error, no process running). In the SP3 Release notes, this problem is not reported. Does anybody has addressed this problem? I'm suspecting SP3 *could* resolve it, but I don't want to download a 600 MB no-useful file. Thanks a lot.Article: 118857
On May 4, 11:24 am, Edson <jelo...@gmail.com> wrote: > I made my testbench and "added" it to the project. WHen i try to run ISE simulator (GEnerate Expected REsults or BEhavioral SImulation), ISE simply does nothing (no message, no error, no process running). When I first tried the ISE simulator my silently firewall blocked it and I got a similar result. No warnings, or errors, it just looked like nothing happened and ISE was happy about it. The ISE simulator creates and compiles a C program that then talks back to ISE through a socket (I think). Because it recompiled every time, ZoneAlarm detected a new program every time and made me click allow (until I turned it off). Alan Nishioka alan@nishioka.comArticle: 118858
Eric Crabill wrote: > Hi Bryan, > > Maybe you saw the video pass through design at an XFEST event or at the > Spartan-3AN press release event? Otherwise, I am not sure how you would > know it exists. If you are looking for that design, please contact your > local FAE or sales representative for assistance. I am not sure if/when > this design will be posted. :) Err.., I think he IS the local FAE / Sales rep, as his address claims Xilinx ?. It maybe that it was an 'oops' posting, meant to go upstream inside Xilinx. [yes, does happen sometimes...] Any comments/release schedules re Antti's questions about DDR2 working examples on 3A demo system ? -jgArticle: 118859
On May 3, 9:47 pm, Tom <tomahawk...@gmail.com> wrote: > Hello, > > Atom is a new high-level hardware description language embedded in > the functional language Haskell. Atom compiles circuit descriptions > in conditional term rewriting systems down to Verilog and VHDL > for IC simulation, verification, and synthesis. > > Programming in Atom feels a lot like object oriented design because > module interfaces use methods, instead of just wires and bits. > > We've used Atom successfully on several different "test" designs > including bus arbitration, packet routing, memory interfaces, > DSP, serial interface controllers, and error correction coding. > In fact, an early version of Atom compiled the 802.11an LDPC > codec posted to opencores.org. > > The language is a bit in flux, and the documentation, tutorial, > and examples are pretty sparse. But if you're interested > in new ways to design hardware, and your not intimidated > by Haskell, give Atom a try. It's free. > > http://funhdl.org/wiki/doku.php/atom > > -Tom Looks interesting, but very little info on the website. How does this compare to Lava (Haskell), HDFS (F#) or i was going to say confluence, (but it looks like confluence is becoming Atom)? Has anyone outside of the developers tried any of these or have opinions?Article: 118860
On May 4, 10:54 am, moo...@yahoo.co.uk wrote: > On 4 May, 18:38, jetm...@hotmail.com wrote: > > > > We are using an FPGA (Xilinx Spartan 3) as a delevlopment platform, > > > and we would like the same functionality. > > > For your prototype you might want to consider my favourite solution: > > > Use two I/O pins instead of one. Consider one of them as "data" pin > > and route it to your peripherial. Consider the other one as "pull" > > pin, and connect it with a 20K resistor to the data pin. > > > For "input", put both pins in tristate. For "pullup", put the data > > pin in tristate, and the pull pin in output-high (the peripherial sees > > 20K pullup). Etc. > > > Kind regards, > > Marc > > We are using an off the shelf development board. Although it has space > for user functionality, this will be taken by our mixed signal test > chip (to form the complete system). > > Thanks, > > Steven Steven, obviously you can configure the part with either pull-up, or pull-down or neither on any individual pin. Austin showed you the drawing. Why are you ineterested in making these changes later on, in a working system? That's really the only thing that is complicated. So, why do you feel it is necessary? Peter AlfkeArticle: 118861
Steve, Thanks for the explanation. AustinArticle: 118862
"Peter Alfke" <peter@xilinx.com> wrote in message
news:1178310010.470676.196160@o5g2000hsb.googlegroups.com...
> On May 4, 10:54 am, moo...@yahoo.co.uk wrote:
>> On 4 May, 18:38, jetm...@hotmail.com wrote:
It appears the use is for GPIO controlled from embedded software which will
be used in the ASIC.
Lost from the original post:
Hi,
Within our ASIC library, we have an I/O pad which has input pins
allowing us to select whether a pullup, pulldown or none is enabled
for this pad.
This is very useful for GPIO.
>> > > We are using an FPGA (Xilinx Spartan 3) as a delevlopment platform,
>> > > and we would like the same functionality.
>>
>> > For your prototype you might want to consider my favourite solution:
>>
>> > Use two I/O pins instead of one. Consider one of them as "data" pin
>> > and route it to your peripherial. Consider the other one as "pull"
>> > pin, and connect it with a 20K resistor to the data pin.
>>
>> > For "input", put both pins in tristate. For "pullup", put the data
>> > pin in tristate, and the pull pin in output-high (the peripherial sees
>> > 20K pullup). Etc.
>>
>> > Kind regards,
>> > Marc
>>
>> We are using an off the shelf development board. Although it has space
>> for user functionality, this will be taken by our mixed signal test
>> chip (to form the complete system).
>>
>> Thanks,
>>
>> Steven
>
> Steven, obviously you can configure the part with either pull-up, or
> pull-down or neither on any individual pin. Austin showed you the
> drawing.
> Why are you ineterested in making these changes later on, in a working
> system?
> That's really the only thing that is complicated. So, why do you feel
> it is necessary?
> Peter Alfke
>
Article: 118863and,,, If you skip up a few replies in this thread, you will see the standard that was written that created this strange requirement. If I was paranoid, I might think that ASIC designers do stuff like this intentionally to prevent anyone from muscling in on their turf with FPGAs. But, that would be silly. AustinArticle: 118864
tkvhdl@gmail.com wrote: > On May 3, 9:47 pm, Tom <tomahawk...@gmail.com> wrote: > >>Hello, >> >>Atom is a new high-level hardware description language embedded in >>the functional language Haskell. <snip>> >> http://funhdl.org/wiki/doku.php/atom > Looks interesting, but very little info on the website. > How does this compare to Lava (Haskell), HDFS (F#) or i was going to > say confluence, (but it looks like confluence is becoming Atom)? > Has anyone outside of the developers tried any of these or have > opinions? > There is also this Python-derived flow : http://myhdl.jandecaluwe.com/doku.php/start How does Atom compare with that? MyHDL is also a 'cross-compiler', that exports verilog code. -jgArticle: 118865
austin wrote: > Mike, > > I got that. > > But why must this be done dynamically, by the logic, while it is working? > > Why not just do this when you configure the part? Since it does not seem to be many pins that need this, why not implement it by allocating two FPGA pins ? Then, you CAN easily control it from the logic, with little PCB cost. With an external resistor, and a terminate pin, you can control the load as PullUp, PullDown, or Float ? -jgArticle: 118866
austin wrote: > and,,, > > If you skip up a few replies in this thread, you will see the standard > that was written that created this strange requirement. > > If I was paranoid, I might think that ASIC designers do stuff like this > intentionally to prevent anyone from muscling in on their turf with FPGAs. > > But, that would be silly. Well, that structure is also common in Microcontrollers, so the one out of step here, is the (much smaller) FPGA sector :) But, as per my other post, you can pretty much create this using two pins on a FPGA, and there are not many IOs where this is vital, so the system cost is small. -jgArticle: 118867
Hi Ben! Thank you for these information, and specially for that sentence: "The synthesis tool is "guaranteed" not to break the functional correctness of your circuit when pruning registers", that's what i wanted to know. Thank you, A.Article: 118868
Hi Jim, I don't usually look at the message headers, because it plays no role in my deciding to answer a question. Maybe Bryan does work with/for Xilinx! In any case, Bryan, I hope I answered your question. You can get a working DDR2 interface from MIG 1.7 specifically for the Spartan-3A Starter Kit. There's also a working design derived from that in the board test design that is posted on the Spartan-3A Starter Kit reference design page. I think what some previous posters wanted was more than "working", rather a "stress test" or something that really demonstrates the bandwidth of the memory interface. I agree that such a demo or reference design would have value. Do I have any comments/release schedules to share? No, sorry. Eric "Jim Granville" <no.spam@designtools.maps.co.nz> wrote in message news:463b885f$1@clear.net.nz... > Eric Crabill wrote: >> Hi Bryan, >> >> Maybe you saw the video pass through design at an XFEST event or at the >> Spartan-3AN press release event? Otherwise, I am not sure how you would >> know it exists. If you are looking for that design, please contact your >> local FAE or sales representative for assistance. I am not sure if/when >> this design will be posted. > > :) Err.., I think he IS the local FAE / Sales rep, as his address claims > Xilinx ?. > > It maybe that it was an 'oops' posting, meant to go upstream inside > Xilinx. [yes, does happen sometimes...] > > Any comments/release schedules re Antti's questions about DDR2 working > examples on 3A demo system ? > > -jg >Article: 118869
On May 4, 2:31 pm, "tkv...@gmail.com" <tki...@gmail.com> wrote: > > Looks interesting, but very little info on the website. > How does this compare to Lava (Haskell), HDFS (F#) or i was going to > say confluence, (but it looks like confluence is becoming Atom)? Lava, HDFS, HDCaml, and Confluence use functional programing to describe the structure of a hardware circuit. In these languages, functions are used to assemble parametric hardware blocks from a collection of logic primitives (eg. gates, arithmetics, comparisons, registers, etc). Lava is step above the crowd in that it also gives the designer control of layout. Even though these languages offer many benefits over Verilog and VHDL, designers still must manually wire up every logic primitive in the design. Thus, one could argue they are still at the register transfer abstraction level (RTL). Atom is bit different. Designers still have to declare registers and combinational functions of these registers, but now Atom synthesizes control logic to connect the combinational functions to the register inputs for the next-state calculations. In a sense, the Atom compiler is now making design decisions that a human has to do today with any RTL HDL (Verilog, VHDL, Lava, HDFS, et al). To address Jim's question in the following post: > There is also this Python-derived flow : > How does Atom compare with that? > MyHDL is also a 'cross-compiler', that exports verilog code. I don't have experience with MyHDL, so my statements may need to be qualified. From what I gather, MyHDL very closely approximates the semantics of Verilog (@always(clock.posedge)). Therefore I suspect, in terms of synthesis, MyHDL is still at RTL. Where MyHDL shines, is it's ability to simulate within it's host language, Python. If locked in a room with SystemVerilog and Python, I'd take Python any day. If offered OCaml or Haskell, I'll always reach for higher-order functional languages. -TomArticle: 118870
Tom wrote: > I don't have experience with MyHDL, so my statements may need to be > qualified. From what > I gather, MyHDL very closely approximates the semantics of Verilog > (@always(clock.posedge)). > Therefore I suspect, in terms of synthesis, MyHDL is still at RTL. I think I disagree. RTL++ anyway. Have a look at this example. source: http://myhdl.jandecaluwe.com/doku.php/cookbook:sinecomp object: http://home.comcast.net/~mike_treseler/sinecomputer.pdf -- Mike TreselerArticle: 118871
On 4 May, 22:20, Peter Alfke <p...@xilinx.com> wrote: > On May 4, 10:54 am, moo...@yahoo.co.uk wrote: > > > > > On 4 May, 18:38, jetm...@hotmail.com wrote: > > > > > We are using an FPGA (Xilinx Spartan 3) as a delevlopment platform, > > > > and we would like the same functionality. > > > > For your prototype you might want to consider my favourite solution: > > > > Use two I/O pins instead of one. Consider one of them as "data" pin > > > and route it to your peripherial. Consider the other one as "pull" > > > pin, and connect it with a 20K resistor to the data pin. > > > > For "input", put both pins in tristate. For "pullup", put the data > > > pin in tristate, and the pull pin in output-high (the peripherial sees > > > 20K pullup). Etc. > > > > Kind regards, > > > Marc > > > We are using an off the shelf development board. Although it has space > > for user functionality, this will be taken by our mixed signal test > > chip (to form the complete system). > > > Thanks, > > > Steven > > Steven, obviously you can configure the part with either pull-up, or > pull-down or neither on any individual pin. Austin showed you the > drawing. > Why are you ineterested in making these changes later on, in a working > system? > That's really the only thing that is complicated. So, why do you feel > it is necessary? > Peter Alfke Hi, The ASIC product we are designing is basically a "generic" microcontoller together with a mixed signal section. The ASIC has a very low pincount, most of which are used for power/ground/clocks. This ASIC will be used in a number of products, each with unique GPIO requirements (thus the programmability). If you check out data sheets for microcontrollers (e.g. PIC), you can see that programmable pull configurations are very common. I can see that for an FPGA based product, then the functionality may not be required (although I would be concerned about supporting N devices intead of 1), but we are using FPGA's as a (F/W and system) development and proving platform so we need minimal changes. The "two pin solution" is interesting and provdes the required functionality, but I am not sure that we have the spare pins/ connectivity etc on our off the FPGA evaluation board (the expansion area will be used for our mixed signal system). Thanks for the feedback, StevenArticle: 118872
On May 4, 10:59 pm, Mike Treseler <mike_trese...@comcast.net> wrote: > Tom wrote: > > I don't have experience with MyHDL, so my statements may need to be > > qualified. From what > > I gather, MyHDL very closely approximates the semantics of Verilog > > (@always(clock.posedge)). > > Therefore I suspect, in terms of synthesis, MyHDL is still at RTL. > > I think I disagree. > RTL++ anyway. > > Have a look at this example. > source:http://myhdl.jandecaluwe.com/doku.php/cookbook:sinecomp I would even say it's RTL# -- there's a ton of cool elaboration taking place. But "yield clock.posedge" is still just an always block. Here's how a cordic processor could look in Atom. Atom's strength is control logic. So for clarity, I'll ignore the datapath details: http://funhdl.org/wiki/doku.php/atom:tutorial:cordic Unlike RTL, Atom's module interfaces are object-oriented. If an external block wants to start a computation, it calls the loadData method. When it wants the result, it calls getResult. In addition, such interfaces support multiple consumers and producers. If two blocks are trying to call loadData at the same time, the Atom compiler will automatically handle the arbitration. More importantly, the Atom compiler guarantees correctness across module interfaces. If CORDIC is known to be correct on the inside, there is nothing an external block can do to break it from the outside. -TomArticle: 118873
Eric Crabill schrieb: > Hi Jim, > > I don't usually look at the message headers, because it plays no role in my > deciding to answer a question. Maybe Bryan does work with/for Xilinx! In > any case, Bryan, I hope I answered your question. > > You can get a working DDR2 interface from MIG 1.7 specifically for the > Spartan-3A Starter Kit. There's also a working design derived from that in > the board test design that is posted on the Spartan-3A Starter Kit reference > design page. I think what some previous posters wanted was more than > "working", rather a "stress test" or something that really demonstrates the > bandwidth of the memory interface. I agree that such a demo or reference > design would have value. Do I have any comments/release schedules to share? > No, sorry. > > Eric > > "Jim Granville" <no.spam@designtools.maps.co.nz> wrote in message > news:463b885f$1@clear.net.nz... > > Eric Crabill wrote: > >> Hi Bryan, > >> > >> Maybe you saw the video pass through design at an XFEST event or at the > >> Spartan-3AN press release event? Otherwise, I am not sure how you would > >> know it exists. If you are looking for that design, please contact your > >> local FAE or sales representative for assistance. I am not sure if/when > >> this design will be posted. > > > > :) Err.., I think he IS the local FAE / Sales rep, as his address claims > > Xilinx ?. > > > > It maybe that it was an 'oops' posting, meant to go upstream inside > > Xilinx. [yes, does happen sometimes...] > > > > Any comments/release schedules re Antti's questions about DDR2 working > > examples on 3A demo system ? > > > > -jg > > Eric, it looks like I am missing something :( 1) the only thing at X-Fest was the rotazoom that takes images from NOR flash no video pass through demo (at X-Fest in Munich) 2) the only "derived" DDR2 design seems to be board test design where PicoBlaze reads out the MIG testbench error led status and displays p or f on hyperterminal - is this the MIG derived design you have been referreing to, or is there some more functional design available? AnttiArticle: 118874
On May 4, 12:47 am, Tom <tomahawk...@gmail.com> wrote: > Atom is a new high-level hardware description language embedded in > the functional language Haskell. Atom compiles circuit descriptions > in conditional term rewriting systems down to Verilog and VHDL > for IC simulation, verification, and synthesis. I'll take a look... Sounds a lot like Bluespec, what can you say about the differences between the two? Edmond
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