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 Friday, December 2, 2016 at 3:10:19 AM UTC-5, o pere o wrote: >=20 > This is a point, although a weak one. The same should also happen to the= =20 > microcontroller industry... but does not. They are quite happy selling=20 > chips that are being programmed by the open-sourced gcc toolchain. >=20 Also consider that on the gcc side of things that they have a lot of people= who know how to write software that are writing and developing the gcc sof= tware. There aren't nearly as many people who know how to write software w= orking on software stuff for hardware like FPGAs. Witness that we don't ha= ve much of anything other than GHDL as a basic simulator. Development on t= hat is up to the whims of one person who chooses to work on it (or not in w= hich case everything stops...as it has of late). It wouldn't surprise me if FPGA companies probably consider that the open s= ource community would take forever to develop anything. KevinArticle: 159526
On 12/2/2016 2:04 AM, Sri G wrote: > I stumbled on that project but its almost 10 years old! Nevertheless, > I reached out to Antti Luktas, hopefully he's not too busy to get > back to me :) > > Making the physical connection isn't too difficult: > https://www.amazon.com/48cm-Sd-micro-Card-Extender-Cable/dp/B007WYRO7O > > > Even jumper cables are suitable at 350 Mhz.. > > The specification for the SD protocol is nearly completely available > in the Simple SD Specification freely available on sdcard.org - the > state machines I'd need are bootup (3.3v), negotiating to high speed > (which switches to 1.8v) and data transfer. > > The SD-MUX option wears out, I've run through a couple SD cards > already which is why I'm looking into the FPGA approach - not to > mention faster in speed. > > I'm uncertain about FPGA sizing and FPGA's in general which is why I > posted here - there doesn't seem to be any relatable data between > different FPGA manufacturers and I'm trying to keep costs low if I > need to make a lot of boards. People say the specs are available, but I looked for the mechanical details and never found them. My understanding is you can use an SD card in SPI mode (one bit data width) but the 4 bit mode is not specified. Maybe that has changed and my info is out of date. I saw the cables when looking for a mail SD card connector. I don't know how well they work. I didn't know SD cards ran at 350 MHz, but at that speed you need to pay careful attention to the details of connections. Signal integrity (SI) can be a significant issue. Even a small FPGA will do the job of providing the SD card interface. The USB interface requires a lot of code (relatively speaking) but is well supported by vendors and various other sources with example code for MCUs. Lattice has a number of low end FPGAs that use internal flash to load the config RAM so an external chip is not needed. That is why Antti used an XP device. They are now obsolete, but Lattice has the XP2, XO2 and XO3 lines in addition to the iCE40 family. The iCE40 line uses one time programmable NVM to load the RAM though. If you want the chip to be reconfigurable in the field you need an external flash chip. -- Rick CArticle: 159527
On 12/2/2016 3:10 AM, o pere o wrote: > On 26/11/16 05:57, rickman wrote: >> On 11/25/2016 4:26 PM, Tim Wescott wrote: >>> >>> Reading this whole thread, I'm reminded of a gripe I have about the FPGA >>> manufacturers, or at least Xilinx and Altera. >>> >>> If they -- or just any one of them -- would PUBLISH the details of how >>> their bitfiles map to the workings of their FPGAs, then all of a sudden >>> that company's stuff would be the subject of all the intensive >>> university >>> research on FPGA optimization that you might desire, and possibly even >>> see an open-source tools ecology grow around its parts. >>> >>> It wouldn't immediately lead to nirvana, but it may at least lead to >>> more >>> and better optimization, and lots of people experimenting with different >>> optimization approaches. >> >> Let's say I am Xilinx... I have a bazillion dollars of investment into >> my products and the support software. I sell to large companies who >> want reliable, consistent products. I open up my chip design and a >> bunch of university idealists start creating tools for my devices. The >> tools work to varying degrees and are used for a number of different >> designs by a wide variety of groups. >> >> So what happens when some of these groups report problems "with the >> chips"? Are these problems really with the chips or with the tools? If >> any of these groups ask us to deal with these problems, how do we begin? >> >> In other words, how do we keep these tools from causing problems with >> our reputation? >> > > This is a point, although a weak one. The same should also happen to the > microcontroller industry... but does not. They are quite happy selling > chips that are being programmed by the open-sourced gcc toolchain. I think this is apples and oranges. It is easy to look at the output of a compiler and see what it is doing. The details of the configuration file for an FPGA is not so easy to analyze. Also, the configuration bit stream isn't just a matter of telling the chip what to do, it can set up internal conflicts that can damage the chip. Even if the FPGA vendors release their technical info on the configuration bit stream, it is a very complex thing to deal with. -- Rick CArticle: 159528
rickman <gnuarm@gmail.com> wrote: > I saw the cables when looking for a mail SD card connector. I don't > know how well they work. I didn't know SD cards ran at 350 MHz, but at > that speed you need to pay careful attention to the details of > connections. Signal integrity (SI) can be a significant issue. UHS-I goes up to 104MHz (104MB/s SDR), and then UHS-II adds a differential interface (up to 312MB/s at present). > Even a small FPGA will do the job of providing the SD card interface. > The USB interface requires a lot of code (relatively speaking) but is > well supported by vendors and various other sources with example code > for MCUs. A small FPGA will handle the physical interface, but implementing the card end of the protocol is more complex (though not as bad as USB). I'd suggest you want to use an FPGA to interface to a CPU (or a soft CPU inside a larger FPGA) and running software to implement the protocol - doing it all in hardware will be pretty painful. Another option might be to take an existing SD card chip and use an FPGA to emulate the NAND flash it's expecting to talk to. The NAND protocol is a lot cleaner than SD. However you'd have to force the SD chip to disabling wear levelling somehow, otherwise it would shuffle your blocks around. It sounds like a somewhat finnicky project, particularly if you're expecting to get decent speed out of it... TheoArticle: 159529
o pere o <me@somewhere.net> wrote: > This is a point, although a weak one. The same should also happen to the > microcontroller industry... but does not. They are quite happy selling > chips that are being programmed by the open-sourced gcc toolchain. An ISA is an API. A lot of work goes on implementing the microarchitecture which implements the API, either in hardware or software (microcode). Another lot of work goes on proving that the implementation matches the API and is bug-free (and 'halt and catch fire' is definitely a bug). FPGA silicon doesn't have an API, you just have the raw transistors to control. The main safeguards to prevent them generating flame-inducing configurations (or more prosaically customer returns) are in the tools. You can put an API on top of an FPGA (eg as the 'FPGA virtualisation' folks do) but the performance and flexibility impact is substantial. As far as I'm aware of the current state of FPGA virtualisation (admittedly not that much), there's nothing there that would be usable in a product anytime soon. TheoArticle: 159530
On Friday, November 25, 2016 at 4:26:11 PM UTC-5, Tim Wescott wrote: >=20 > If they -- or just any one of them -- would PUBLISH the details of how=20 > their bitfiles map to the workings of their FPGAs, then all of a sudden= =20 > that company's stuff would be the subject of all the intensive university= =20 > research on FPGA optimization that you might desire, and possibly even=20 > see an open-source tools ecology grow around its parts. >=20 I kind of doubt that would happen. I don't think there are enough hardware= knowledgeable folks who can write good software. If there were, we would = all be simulating with some open source VHDL+Verilog simulator that puts Mo= delsim and Aldec to shame [1]. But instead most people I think are using M= odelsim/Aldec or some lame simulator that comes bundled with the tools. Since there apparently aren't many folks diving in to develop something tha= t would benefit many with a decent simulator, why would you think there wou= ld be enough to dive in and help develop something that benefits a subset o= f that market? Open source developers tend to use their tools in their day to day work as = well. Those developers 'only' need to be good at developing software in or= der to develop open source stuff. When you talk about open source tools to= be used for hardware development, you would want to have someone good at d= eveloping hardware and software so that the tools they develop they would t= hen use day to day. If nothing else, there are fewer of those folks that h= ave both skills and, based on the lack of developers for open source simula= tors, I think there just isn't the critical mass. Manufacturers keeping their details secret could be seen as nothing more th= an their seeing that there aren't enough people out there who could even de= velop what is needed in an open source scenario. So they pay people to dev= elop what they need. > It wouldn't immediately lead to nirvana, but it may at least lead to more= =20 > and better optimization, and lots of people experimenting with different= =20 > optimization approaches. >=20 I know you're not holding your breath waiting for that nirvana...but I'd wa= ger that you will have taken your last breath long before such nirvana was = reached. Kevin Jennings [1] Yes I know about GHDL and it is and appears to have always been a one m= an band. The original band member left the band and years later someone el= se picked it up. Last two releases are 0.31 released in Oct-2015 and 0.33 = in Dec-2015, nothing new in about 12 months and counting. It is still not = up to release 1.0 and there will be another revision to the VHDL standard i= n 2017. One person can only do so much...in addition to doing something th= at puts food on the table.Article: 159531
On Friday, December 2, 2016 at 3:41:04 PM UTC-5, KJ wrote: > > [1] Yes I know about GHDL <snip> > Last two releases are 0.31 released in Oct-2015 and 0.33 in Dec-2015, > nothing new in about 12 months and counting. > Tristan moved the development to GitHub: https://github.com/tgingold/ghdl/releases -BrianArticle: 159532
On Friday, December 2, 2016 at 7:28:42 PM UTC-5, Brian Davis wrote: > On Friday, December 2, 2016 at 3:41:04 PM UTC-5, KJ wrote: > > > > [1] Yes I know about GHDL <snip> > > Last two releases are 0.31 released in Oct-2015 and 0.33 in Dec-2015, > > nothing new in about 12 months and counting. > > > Tristan moved the development to GitHub: > https://github.com/tgingold/ghdl/releases That's good to hear, now you need to let Google in on the secret. I do see= there is mention of the move to Github on the summary page on SourceForge = page, but maybe you should consider pulling all the old stuff down from Sou= rceForge and put some more redirection links to the new home. Kevin JenningsArticle: 159533
> I kind of doubt that would happen. I don't think there are enough hardwa= re knowledgeable folks who can write good software. If there were, we woul= d all be simulating with some open source VHDL+Verilog simulator that puts = Modelsim and Aldec to shame [1]. But instead most people I think are using= Modelsim/Aldec or some lame simulator that comes bundled with the tools. I agree. It doesn't seem likely that there would be a lot of people versed= in low-level silicon design and high-level software and who would also be = willing to put in a lot of time for free. I don't suppose there is anything stopping somebody from making a synthesiz= er--you can just convert RTL into structural HDL containing primitives--but= I don't see a lot of free synthesizers around.Article: 159534
On Fri, 2 Dec 2016 03:32:16 -0800 (PST) KJ <kkjennings@sbcglobal.net> wrote: > Also consider that on the gcc side of things that they have a > lot of people who know how to write software that are writing > and developing the gcc software. There aren't nearly as many > people who know how to write software working on software > stuff for hardware like FPGAs. Witness that we don't have > much of anything other than GHDL as a basic simulator. > Development on that is up to the whims of one person who > chooses to work on it (or not in which case everything > stops...as it has of late). The MyHDL community is vibrant [1], and this fast[2] simulator exports Verilog and VHDL for synthesis. > It wouldn't surprise me if FPGA companies probably consider > that the open source community would take forever to develop > anything. I'm using open source tools [3]. As for community, there are many users, not sure about developers, maybe clues here [4]. Clifford did/does warn about frying chips, but the value of the project far exceeds the cost of a few sacrificial ICs. Jan Coombs -- [1] http://myhdl.org/ [2] http://myhdl.org/docs/performance.html [3] http://www.clifford.at/icestorm/ [4] https://www.reddit.com/r/yosys/comments/4ocilz/icestorm_adding_support_for_new_devices_part_1/Article: 159535
responding to http://www.electrondepot.com/fpga/help-finding-xilinx-software-for-hw-130-programmer-81804-.htm , Joe Z wrote: > gnuarm wrote: > > On 5/3/2016 2:23 PM, Tim Regeant wrote: > > I am searching for some Xilinx programmer software for the HW-130 > unit > > from around 1996-2000. > > > > Looking the the DOS version. The filename was HW130.ZIP > > > > Also looking for the 16-bit windows version HW130W.ZIP. > > > > Thank you for any help you can offer! > > I have software from that era along with a license key. I could get it > > to you. > > -- > > Rick C > Hi Rick, I'm in the same boat - I have an old XC17S that I need to read and re-create. I'm planning to grab an HW-130 on ebay, but the software for it is nowhere to be had... Can you email it to me too? -Joe ZArticle: 159536
On 12/5/2016 10:37 PM, Joe Z wrote: > responding to > http://www.electrondepot.com/fpga/help-finding-xilinx-software-for-hw-130-programmer-81804-.htm > > , Joe Z wrote: >> gnuarm wrote: >> >> On 5/3/2016 2:23 PM, Tim Regeant wrote: > I am searching for some >> Xilinx programmer software for the HW-130 >> unit > from around 1996-2000. > > Looking the the DOS version. The >> filename was HW130.ZIP > > Also looking for the 16-bit windows version >> HW130W.ZIP. > > Thank you for any help you can offer! >> I have software from that era along with a license key. I could get it >> to you. >> -- >> Rick C > > Hi Rick, > > I'm in the same boat - I have an old XC17S that I need to read and > re-create. I'm planning to grab an HW-130 on ebay, but the software for > it is nowhere to > be had... Can you email it to me too? It was on a number of disks along with several dongles. I already sent it to whoever it was that wanted it. It took me forever to find it. My office is a total mess these days as I haven't really worked there for some time and it has become the warehouse from Indiana Jones. But it did finally turn up and I put it in the mail. -- Rick CArticle: 159537
I keep debating if I should start switching my PCs from Windows 10 to Linux, several of my main PCs are on Win 10 Preview, and Microsoft made it so you can't get off until the next non-preview release. I play around with Lattice, and Xilinx FPGAs, I know Lattice has their Diamond software available for Linux, and Xilinx has Vivado and it's older software also available for Linux also, but I've read that it's difficult to get them to work with Linux. I use Mint Linux X64 a derivative of Ubuntu, so anyone out there has used with with either of that software and how difficult was it to get it working? Thanks -- Cecil - k5nwaArticle: 159538
On 06/12/16 05:59, Cecil Bayona wrote: > I keep debating if I should start switching my PCs from Windows 10 to Linux, > several of my main PCs are on Win 10 Preview, and Microsoft made it so you can't > get off until the next non-preview release. > > I play around with Lattice, and Xilinx FPGAs, I know Lattice has their Diamond > software available for Linux, and Xilinx has Vivado and it's older software also > available for Linux also, but I've read that it's difficult to get them to work > with Linux. > > I use Mint Linux X64 a derivative of Ubuntu, so anyone out there has used with > with either of that software and how difficult was it to get it working? Vivado on Xubuntu was trivial to install and get working. Personally I would expect it to be more difficult to get it working on Windows, but the manufacturer should have sorted that out. If in doubt, download it and install it in a virtual machine image. There's even an argument that should be done for the work environment, particularly if you might need to revisit a design later.Article: 159539
On 12/6/2016 2:56 AM, Tom Gardner wrote: > On 06/12/16 05:59, Cecil Bayona wrote: >> I keep debating if I should start switching my PCs from Windows 10 to >> Linux, >> several of my main PCs are on Win 10 Preview, and Microsoft made it so >> you can't >> get off until the next non-preview release. >> >> I play around with Lattice, and Xilinx FPGAs, I know Lattice has their >> Diamond >> software available for Linux, and Xilinx has Vivado and it's older >> software also >> available for Linux also, but I've read that it's difficult to get >> them to work >> with Linux. >> >> I use Mint Linux X64 a derivative of Ubuntu, so anyone out there has >> used with >> with either of that software and how difficult was it to get it working? > > Vivado on Xubuntu was trivial to install and get working. > Personally I would expect it to be more difficult to get > it working on Windows, but the manufacturer should have > sorted that out. > > If in doubt, download it and install it in a virtual machine > image. There's even an argument that should be done for the > work environment, particularly if you might need to revisit > a design later. > Are you speaking of using a virtual PC for the development? Under Windows 10 I also setup two Virtual CPUs running Win 7 i386 and X64 because some of the software development tools would not work with Windows 10 and some had issues with X64. I was a little slower but not by much mostly because the Diamond software had less RAM under the 32 bit Virtual PC but it was good enough. An advantage was I could copy the VM to any other PC I desired with little effort, and it was easy to keep a backup of the entire system. I used vmWare and had little difficulty having the VM talk to the FPGA board. Right now I mostly use the Win 7 X64 VM most of the time with few issues rather than use Windows 10 where I have more problems than Windows 7. I supposed it might be better if I took one of my Window 10 CPUs, image it, then restore Window 7 and run that natively but I like to give Linux a shot at it since my machines that have Mint Linux just work and rarely have any problems like Windows does. -- Cecil - k5nwaArticle: 159540
On 06/12/16 09:27, Cecil Bayona wrote: > On 12/6/2016 2:56 AM, Tom Gardner wrote: >> On 06/12/16 05:59, Cecil Bayona wrote: >>> I keep debating if I should start switching my PCs from Windows 10 to >>> Linux, >>> several of my main PCs are on Win 10 Preview, and Microsoft made it so >>> you can't >>> get off until the next non-preview release. >>> >>> I play around with Lattice, and Xilinx FPGAs, I know Lattice has their >>> Diamond >>> software available for Linux, and Xilinx has Vivado and it's older >>> software also >>> available for Linux also, but I've read that it's difficult to get >>> them to work >>> with Linux. >>> >>> I use Mint Linux X64 a derivative of Ubuntu, so anyone out there has >>> used with >>> with either of that software and how difficult was it to get it working? >> >> Vivado on Xubuntu was trivial to install and get working. >> Personally I would expect it to be more difficult to get >> it working on Windows, but the manufacturer should have >> sorted that out. >> >> If in doubt, download it and install it in a virtual machine >> image. There's even an argument that should be done for the >> work environment, particularly if you might need to revisit >> a design later. >> > > Are you speaking of using a virtual PC for the development? That's the argument. There are pros and cons, of course. > Under Windows 10 I also setup two Virtual CPUs running Win 7 i386 and X64 > because some of the software development tools would not work with Windows 10 > and some had issues with X64. I was a little slower but not by much mostly > because the Diamond software had less RAM under the 32 bit Virtual PC but it was > good enough. An advantage was I could copy the VM to any other PC I desired with > little effort, and it was easy to keep a backup of the entire system. I used > vmWare and had little difficulty having the VM talk to the FPGA board. Why am I not surprised! That illustrates a pro of the VM approach. > Right now I mostly use the Win 7 X64 VM most of the time with few issues rather > than use Windows 10 where I have more problems than Windows 7. I supposed it > might be better if I took one of my Window 10 CPUs, image it, then restore > Window 7 and run that natively but I like to give Linux a shot at it since my > machines that have Mint Linux just work and rarely have any problems like > Windows does. On the rare occasions when I need Windows, I run XP in a VM. I have both fully patched and from-the-CD images, and clone them when experimenting. I have no plans to buy Win10; I don't think I'm clever enough to keep it secure.Article: 159541
On 12/5/2016 10:37 PM, Joe Z wrote: > responding to > http://www.electrondepot.com/fpga/help-finding-xilinx-software-for-hw-130-programmer-81804-.htm > > , Joe Z wrote: >> gnuarm wrote: >> >> On 5/3/2016 2:23 PM, Tim Regeant wrote: > I am searching for some >> Xilinx programmer software for the HW-130 >> unit > from around 1996-2000. > > Looking the the DOS version. The >> filename was HW130.ZIP > > Also looking for the 16-bit windows version >> HW130W.ZIP. > > Thank you for any help you can offer! >> I have software from that era along with a license key. I could get it >> to you. >> -- >> Rick C > > Hi Rick, > > I'm in the same boat - I have an old XC17S that I need to read and > re-create. I'm planning to grab an HW-130 on ebay, but the software for > it is nowhere to > be had... Can you email it to me too? > > -Joe Z > > > Send me an email with what you need. I have the software.Article: 159542
Hi Svenn, I recently released a new version of the TimingAnalyzer that includes the p= ython function you requested. I'm also working on creating cycle accurate = VHDL testbenches that read test vectors created from timing diagrams that r= epresent transactions. This might be something else you would be intereste= d in since you working with VHDL. =20 If anyone is interested in following the work being done or contributing to= new feature ideas, join the google group. Regards, Dan www.timing-diagrams.com http://groups.google.com/group/timinganalyzer =20Article: 159543
I have a "Cyclone V GX Starter Board," with an Altera Cyclone V GX 5CGXFC5CF27C7N. I've designed a logic layout for a video card that only does SVGA output in graphics modes, and particularly only 1024 x 768 x 75 Hz refresh rate right now. I've developed a custom protocol for using single bytes per pixel, and a palette of 256 colors from a possible range of 4,096 colors. ----- I've gotten everything designed and I'd like to put it to hardware now. I honestly don't know where to begin on this Altera. I'd like to double-clock the pixel clock so I can conduct operations in-between use. It requires about a 79 MHz clock at 1024x768x75, so I'd need about a 168 MHz clock. Can somebody point me in the right direction, please? Best regards, Rick C. HodginArticle: 159544
Rick C. Hodgin <rick.c.hodgin@gmail.com> wrote: > I've gotten everything designed and I'd like to put it to hardware > now. I honestly don't know where to begin on this Altera. > > I'd like to double-clock the pixel clock so I can conduct operations > in-between use. It requires about a 79 MHz clock at 1024x768x75, > so I'd need about a 168 MHz clock. > > Can somebody point me in the right direction, please? You need a PLL. You can either: Go to IP Catalog in Quartus and instantiate one. This has a wizard that asks you all the questions and generates some Verilog that does it. It's then up to you to wire it up. or If you use Qsys (a good idea) you can just drop in a PLL component and fill in the answers to the questions. You can then connect up the ports with the clicky interface - which will also keep track of your clock domains and insert clock crossing buffers where needed. TheoArticle: 159545
On Wednesday, December 7, 2016 at 2:09:37 PM UTC-5, Theo Markettos wrote: > Rick C. Hodgin <rick.c.hodgin@gmail.com> wrote: > > I've gotten everything designed and I'd like to put it to hardware > > now. I honestly don't know where to begin on this Altera. > > > > I'd like to double-clock the pixel clock so I can conduct operations > > in-between use. It requires about a 79 MHz clock at 1024x768x75, > > so I'd need about a 168 MHz clock. > > > > Can somebody point me in the right direction, please? > > You need a PLL. You can either: > > Go to IP Catalog in Quartus and instantiate one. This has a wizard that > asks you all the questions and generates some Verilog that does it. It's > then up to you to wire it up. > > or > > If you use Qsys (a good idea) you can just drop in a PLL component and fill > in the answers to the questions. You can then connect up the ports with the > clicky interface - which will also keep track of your clock domains and > insert clock crossing buffers where needed. > > Theo Will I be able to create a 158 MHz clock on this device? Or is that beyond its abilities? Also, I have add and compare circuits that need to run at about 79 MHz. Will those work properly? I'm moving from the area of digital theory design to FPGA programming reality. I'm not sure what to expect. Best regards, Rick C. HodginArticle: 159546
Rick C. Hodgin <rick.c.hodgin@gmail.com> wrote: > Will I be able to create a 158 MHz clock on this device? Or is that > beyond its abilities? Also, I have add and compare circuits that need > to run at about 79 MHz. Will those work properly? The /device/ should be capable of up to 300-400MHz - at least that's what I've seem in general use. However it's your problem to make a design that will run at the speed you use to run it at. I wouldn't have thought you would have big problems at 79MHz, and might be OK at 158MHz - it really depends. TimeQuest timing analyser will tell you, among other things, the maximum clock speed that each clock domain will run at. Assuming you have constrained your input clocks appropriately (ie have an SDC file that indicates their speeds, and any relations between them) then Timequest will warn if your design fails to meet your timing constraints. If you have a PLL, it knows the input clock and will calculate the speeds of the generated clocks, so in general you just need to tell it the input speeds and it'll figure out the rest. > I'm moving from the area of digital theory design to FPGA programming > reality. I'm not sure what to expect. You might find it useful to have a read through an intro to the tools - for instance this my brief rundown aimed at second year university students (in the middle of a course doing other things including verilog and bare-metal software development): http://www.cl.cam.ac.uk/teaching/1617/ECAD+Arch/fpga-intro.html TheoArticle: 159547
On Wednesday, December 7, 2016 at 3:07:21 PM UTC-5, Theo Markettos wrote: > Rick C. Hodgin <rick.c.hodgin@gmail.com> wrote: > > Will I be able to create a 158 MHz clock on this device? Or is that > > beyond its abilities? Also, I have add and compare circuits that need > > to run at about 79 MHz. Will those work properly? > > The /device/ should be capable of up to 300-400MHz - at least that's what > I've seem in general use. However it's your problem to make a design that > will run at the speed you use to run it at. I wouldn't have thought you > would have big problems at 79MHz, and might be OK at 158MHz - it really > depends. > > TimeQuest timing analyser will tell you, among other things, the maximum > clock speed that each clock domain will run at. Assuming you have > constrained your input clocks appropriately (ie have an SDC file that > indicates their speeds, and any relations between them) then Timequest will > warn if your design fails to meet your timing constraints. If you have a > PLL, it knows the input clock and will calculate the speeds of the generated > clocks, so in general you just need to tell it the input speeds and it'll > figure out the rest. > > > I'm moving from the area of digital theory design to FPGA programming > > reality. I'm not sure what to expect. > > You might find it useful to have a read through an intro to the tools - for > instance this my brief rundown aimed at second year university students (in > the middle of a course doing other things including verilog and > bare-metal software development): > > http://www.cl.cam.ac.uk/teaching/1617/ECAD+Arch/fpga-intro.html > > Theo Excellent info. Thank you, Theo. I'm meeting with a local hardware project Meetup group this weekend, so hopefully I'll pick up a few pointers. They typically go over a design and build from beginning to end that one of the members from the group has already had success in getting it to work. Best regards, Rick C. HodginArticle: 159548
On Wednesday, December 7, 2016 at 3:45:10 PM UTC-5, Rick C. Hodgin wrote: > On Wednesday, December 7, 2016 at 3:07:21 PM UTC-5, Theo Markettos wrote: > > Rick C. Hodgin <rick.c.hodgin@gmail.com> wrote: > > > Will I be able to create a 158 MHz clock on this device? Or is that > > > beyond its abilities? Also, I have add and compare circuits that need > > > to run at about 79 MHz. Will those work properly? > > > > The /device/ should be capable of up to 300-400MHz - at least that's what > > I've seem in general use. However it's your problem to make a design that > > will run at the speed you use to run it at. I wouldn't have thought you > > would have big problems at 79MHz, and might be OK at 158MHz - it really > > depends. > > > > TimeQuest timing analyser will tell you, among other things, the maximum > > clock speed that each clock domain will run at. Assuming you have > > constrained your input clocks appropriately (ie have an SDC file that > > indicates their speeds, and any relations between them) then Timequest will > > warn if your design fails to meet your timing constraints. If you have a > > PLL, it knows the input clock and will calculate the speeds of the generated > > clocks, so in general you just need to tell it the input speeds and it'll > > figure out the rest. > > > > > I'm moving from the area of digital theory design to FPGA programming > > > reality. I'm not sure what to expect. > > > > You might find it useful to have a read through an intro to the tools - for > > instance this my brief rundown aimed at second year university students (in > > the middle of a course doing other things including verilog and > > bare-metal software development): > > > > http://www.cl.cam.ac.uk/teaching/1617/ECAD+Arch/fpga-intro.html > > > > Theo > > Excellent info. Thank you, Theo. > > I'm meeting with a local hardware project Meetup group this weekend, > so hopefully I'll pick up a few pointers. They typically go over a > design and build from beginning to end that one of the members from > the group has already had success in getting it to work. I'm going to start by trying to get the address generation circuit and read memory working. I have designed a staging register, and a use register, so the next 8-byte read can come in the background while the pixel clock is shifting between 8-bit blocks in the use register. I think this will provide adequate timing for video modes even well beyond 1024 x 768 x 75 Hz. Best regards, Rick C. HodginArticle: 159549
On Thursday, December 8, 2016 at 3:12:44 PM UTC-5, Rick C. Hodgin wrote: > On Wednesday, December 7, 2016 at 3:45:10 PM UTC-5, Rick C. Hodgin wrote: > > On Wednesday, December 7, 2016 at 3:07:21 PM UTC-5, Theo Markettos wrote: > > > Rick C. Hodgin <rick.c.hodgin@gmail.com> wrote: > > > > Will I be able to create a 158 MHz clock on this device? Or is that > > > > beyond its abilities? Also, I have add and compare circuits that need > > > > to run at about 79 MHz. Will those work properly? > > > > > > The /device/ should be capable of up to 300-400MHz - at least that's what > > > I've seem in general use. However it's your problem to make a design that > > > will run at the speed you use to run it at. I wouldn't have thought you > > > would have big problems at 79MHz, and might be OK at 158MHz - it really > > > depends. > > > > > > TimeQuest timing analyser will tell you, among other things, the maximum > > > clock speed that each clock domain will run at. Assuming you have > > > constrained your input clocks appropriately (ie have an SDC file that > > > indicates their speeds, and any relations between them) then Timequest will > > > warn if your design fails to meet your timing constraints. If you have a > > > PLL, it knows the input clock and will calculate the speeds of the generated > > > clocks, so in general you just need to tell it the input speeds and it'll > > > figure out the rest. > > > > > > > I'm moving from the area of digital theory design to FPGA programming > > > > reality. I'm not sure what to expect. > > > > > > You might find it useful to have a read through an intro to the tools - for > > > instance this my brief rundown aimed at second year university students (in > > > the middle of a course doing other things including verilog and > > > bare-metal software development): > > > > > > http://www.cl.cam.ac.uk/teaching/1617/ECAD+Arch/fpga-intro.html > > > > > > Theo > > > > Excellent info. Thank you, Theo. > > > > I'm meeting with a local hardware project Meetup group this weekend, > > so hopefully I'll pick up a few pointers. They typically go over a > > design and build from beginning to end that one of the members from > > the group has already had success in getting it to work. > > I'm going to start by trying to get the address generation circuit and > read memory working. I have designed a staging register, and a use > register, so the next 8-byte read can come in the background while the > pixel clock is shifting between 8-bit blocks in the use register. > > I think this will provide adequate timing for video modes even well > beyond 1024 x 768 x 75 Hz. I began working with Altera's Quartus II software last night and had difficulty in understanding how it works. In addition, as I began to write verilog code to reproduce my design, it loses so much in the translation into text. I've decided to complete my Logician tool so I can do a graphical design and then have it generate gate, wire, and net verilog source code for compilation in the tool. I'm an image/design-thinker ... not a convert-to-text-thinker. :-) Best regards, Rick C. Hodgin
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