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, June 2, 2017 at 4:55:42 PM UTC-6, Ilya Kalistru wrote: > Hi! > During the discussion about "Test Driven Design?" I promised to write a paper about Non-Project Mode and how it helps with testing. > The problem is that I have never written any article. Moreover, English is not my native language. > I kindly ask you to review the article and help me to improve it. It is in Google docs and leaving comments right in the document is allowed. You also can comment it here if it is more convenient for you. > Thanks. > > https://docs.google.com/document/d/17LgQjxYdh8Dxy4NdFWWNYQ7up8MFNG4GQdPfv3s5LzI/edit?usp=sharing Thanks. I'm in the sim phase on my project right now but when I get back into PAR I'm going to check this out.Article: 160126
On Saturday, June 10, 2017 at 11:42:47 PM UTC+3, Kevin Neilson wrote: > On Friday, June 2, 2017 at 4:55:42 PM UTC-6, Ilya Kalistru wrote: > > Hi! > > During the discussion about "Test Driven Design?" I promised to write a paper about Non-Project Mode and how it helps with testing. > > The problem is that I have never written any article. Moreover, English is not my native language. > > I kindly ask you to review the article and help me to improve it. It is in Google docs and leaving comments right in the document is allowed. You also can comment it here if it is more convenient for you. > > Thanks. > > > > https://docs.google.com/document/d/17LgQjxYdh8Dxy4NdFWWNYQ7up8MFNG4GQdPfv3s5LzI/edit?usp=sharing > > Thanks. I'm in the sim phase on my project right now but when I get back into PAR I'm going to check this out. I have closed access to the draft of the article because I shared it for some time just to get some reviews and suggestions. I'll publish the article as soon as it is reviewed by my employer. Kevin, if you have an Google account you can request access to the draft and I'll grant it to you.Article: 160127
Ilya Kalistru <stebanoid@gmail.com> wrote: > I have closed access to the draft of the article because I shared it > for some time just to get some reviews and suggestions. It looked fine to me. It did suffer slightly from falling into the strangely common trap of assuming FPGA=Xilinx, so maybe that should be signposted up front a bit more. (It's possible to do similar things with Altera but I think the article would need too much restructuring to account for different ways of doing things. I'm not familiar enough with Lattice or Microsemi to comment on those toolchains) TheoArticle: 160128
On Monday, 12 June 2017 13:02:54 UTC+3, Theo Markettos wrote: > It looked fine to me. It did suffer slightly from falling into the > strangely common trap of assuming FPGA=3DXilinx, so maybe that should be > signposted up front a bit more. >=20 > (It's possible to do similar things with Altera but I think the article > would need too much restructuring to account for different ways of doing > things. I'm not familiar enough with Lattice or Microsemi to comment on > those toolchains) >=20 > Theo Thank you for your response. On one hand, I tried not to make the article too Xilinx-specific because I = believe that other tool chains have the same problems and that they likely = to have similar modes of operation. On the other hand, I do not have non-Xi= linx experience to make any specific advice for other toolchains. I see tha= t I need to rework the beginning of the paper to make it clear.Article: 160129
On 06/12/2017 10:40 AM, Ilya Kalistru wrote: > On Monday, 12 June 2017 13:02:54 UTC+3, Theo Markettos wrote: > >> It looked fine to me. It did suffer slightly from falling into the >> strangely common trap of assuming FPGA=Xilinx, so maybe that should be >> signposted up front a bit more. >> >> (It's possible to do similar things with Altera but I think the article >> would need too much restructuring to account for different ways of doing >> things. I'm not familiar enough with Lattice or Microsemi to comment on >> those toolchains) >> >> Theo > > Thank you for your response. > > On one hand, I tried not to make the article too Xilinx-specific because I believe that other tool chains have the same problems and that they likely to have similar modes of operation. On the other hand, I do not have non-Xilinx experience to make any specific advice for other toolchains. I see that I need to rework the beginning of the paper to make it clear. > I'd avoid trying to be too generic. I've set up Makefile based flows under both Xilinx (ISE) and Altera Quartus and they have nothing to do with one another. Totally different paradigms, problems, syntaxes, etc. As near as I was able to tell while you had that document publicly available, you're trying to describe how to a non-project flow under Vivado at this current point in time. That's valuable and helpful. If you haven't made it public again about a month from how I'll probably start harassing you for a copy by email. Better to do that well than to half-ass a generic document that almost by definition can't be right. -- Rob Gaddi, Highland Technology -- www.highlandtechnology.com Email address domain is currently out of order. See above to fix.Article: 160130
I need to accomplish several formal steps before publishing it. It uses some code I've written on my workplace and, therefore, I must obey corporate rules of publishing articles. As soon as I get the article reviewed by my boss and colleagues, I'll try to publish it on fpgarelated.com and may be somewhere else.Article: 160131
Hi all. I'm stopped. Lattice Diamond does not offer a configuration for designing w= ith my part in the 48-VFQFN package. The LCMXO2-640HC-6SG48I is not availab= le in the drop-down configuration menu. They say the closest they can get i= s the TQFP-100 or CSBGA-132 packages. My PCB and FPGA arrived days ago but = I need a way to do development! Is there a way to configure Lattice Diamond= so that it supports this 48 pin QFN device, please? Thanks! --LenArticle: 160132
len.turnbow@gmail.com wrote on 6/16/2017 12:40 AM: > Hi all. > > I'm stopped. Lattice Diamond does not offer a configuration for designing with my part in the 48-VFQFN package. The LCMXO2-640HC-6SG48I is not available in the drop-down configuration menu. They say the closest they can get is the TQFP-100 or CSBGA-132 packages. My PCB and FPGA arrived days ago but I need a way to do development! Is there a way to configure Lattice Diamond so that it supports this 48 pin QFN device, please? What version of Diamond do you have? Maybe you need to update? -- Rick CArticle: 160133
On Thursday, June 15, 2017 at 11:12:30 PM UTC-7, rickman wrote: > > Hi all. > > > > I'm stopped. Lattice Diamond does not offer a configuration for designi= ng with my part in the 48-VFQFN package. The LCMXO2-640HC-6SG48I is not ava= ilable in the drop-down configuration menu. They say the closest they can g= et is the TQFP-100 or CSBGA-132 packages. My PCB and FPGA arrived days ago = but I need a way to do development! Is there a way to configure Lattice Dia= mond so that it supports this 48 pin QFN device, please? >=20 > What version of Diamond do you have? Maybe you need to update? Hi Rick. Well, heck. I'd downloaded and patched 3.9 and assumed that the ic= on on my desktop was linked to the latest version. I was linked to 3.6 inst= ead. I see that my 3.9 *does* support the QFN48 package.=20 Is my face red or what. Thanks! --LenArticle: 160134
On 6/16/2017 1:44 AM, len.turnbow@gmail.com wrote: > On Thursday, June 15, 2017 at 11:12:30 PM UTC-7, rickman wrote: >>> Hi all. >>> >>> I'm stopped. Lattice Diamond does not offer a configuration for designing with my part in the 48-VFQFN package. The LCMXO2-640HC-6SG48I is not available in the drop-down configuration menu. They say the closest they can get is the TQFP-100 or CSBGA-132 packages. My PCB and FPGA arrived days ago but I need a way to do development! Is there a way to configure Lattice Diamond so that it supports this 48 pin QFN device, please? >> >> What version of Diamond do you have? Maybe you need to update? > > Hi Rick. Well, heck. I'd downloaded and patched 3.9 and assumed that the icon on my desktop was linked to the latest version. I was linked to 3.6 instead. > I see that my 3.9 *does* support the QFN48 package. > Is my face red or what. Thanks! > --Len > That is both useful and annoying all at the same time. Sometime back I found by accident that when one upgrades Lattice Diamond it really doesn't update the software but install a new version while the original version is still there. Nice if you want multiple versions but if you don't it's confusing and eats extra space, so now I uninstall the old Lattice Diamond before installing the new version, and I keep the license in a separate folder from the software. -- Cecil - k5nwaArticle: 160135
len.turnbow@gmail.com wrote on 6/16/2017 2:44 AM: > On Thursday, June 15, 2017 at 11:12:30 PM UTC-7, rickman wrote: >>> Hi all. >>> >>> I'm stopped. Lattice Diamond does not offer a configuration for designing with my part in the 48-VFQFN package. The LCMXO2-640HC-6SG48I is not available in the drop-down configuration menu. They say the closest they can get is the TQFP-100 or CSBGA-132 packages. My PCB and FPGA arrived days ago but I need a way to do development! Is there a way to configure Lattice Diamond so that it supports this 48 pin QFN device, please? >> >> What version of Diamond do you have? Maybe you need to update? > > Hi Rick. Well, heck. I'd downloaded and patched 3.9 and assumed that the icon on my desktop was linked to the latest version. I was linked to 3.6 instead. > I see that my 3.9 *does* support the QFN48 package. > Is my face red or what. Thanks! I can't see your face, so I don't know what color it is... lol I noticed some time back that Lattice installed each new version in a new folder and does not delete the old version. Personally I think this is a *very* good thing so that if something in your code breaks with the new version you can still use the old without uninstalling the new. I also was not aware they had added a 48-QFN to the XO2 line and even more important (to me) they've added an 84 pin QFN with 68 I/Os! That would replace an XP part I had in production that is now EOL. I can still buy them, but the price keeps going up. Not sure I'll get any more orders, but if I do I can do a respin of the board and use the XO2 device. -- Rick CArticle: 160136
len.turnbow@gmail.com wrote: > On Thursday, June 15, 2017 at 11:12:30 PM UTC-7, rickman wrote: >> > Hi all. >> > >> > I'm stopped. Lattice Diamond does not offer a configuration for >> > designing with my part in the 48-VFQFN package. The LCMXO2-640HC-6SG48I >> > is not available in the drop-down configuration menu. They say the >> > closest they can get is the TQFP-100 or CSBGA-132 packages. My PCB and >> > FPGA arrived days ago but I need a way to do development! Is there a >> > way to configure Lattice Diamond so that it supports this 48 pin QFN >> > device, please? >> >> What version of Diamond do you have? Maybe you need to update? > > Hi Rick. Well, heck. I'd downloaded and patched 3.9 and assumed that the > icon on my desktop was linked to the latest version. I was linked to 3.6 > instead. I see that my 3.9 *does* support the QFN48 package. > Is my face red or what. Thanks! > --Len Nah, this is minor. if you'd had PC boards fabbed for a part that didn't exist, that would make one's face red. JonArticle: 160137
Hi Everyone, Perhaps you may have a skill to create FPGA and create a clone for 1974 MOS= TEK MK5017, famous clock chip by Heathkit. They used this chip on model GC-= 1005 and run with Panaplex display tubes by Sperry Rand. Unfortunately, MOS= TEK went out of business (thanks to US EPA that destroyed wonderful company= by enormous fines instead of help to clean). Nowdays, it is impossible to find workable MK5017 (several series)to handle= the circuit created by Heathkit (again this company ceased due gross misma= naged by Zenith Radio Corporation). I do not have skill to do with FPGA and VHDL and create soft based MK5017. = Perhaps you may have a skill do that. Heathkit GC-1005 schematic is availab= le at many websites for download at no cost. The most difficult to find is datasheet for MK5017 until today, I found it.= Enclosed the datasheet to help you to create for the FPGA and may need mod= ify the circuit if possible. I cannot add file here but if you are interesting and let me know then I ca= n send you the datasheet. Thank you very much, SFArticle: 160138
steven.feinsmith@gmail.com wrote on 6/19/2017 9:09 PM: > Hi Everyone, > > Perhaps you may have a skill to create FPGA and create a clone for 1974 MOSTEK MK5017, famous clock chip by Heathkit. They used this chip on model GC-1005 and run with Panaplex display tubes by Sperry Rand. Unfortunately, MOSTEK went out of business (thanks to US EPA that destroyed wonderful company by enormous fines instead of help to clean). > > Nowdays, it is impossible to find workable MK5017 (several series)to handle the circuit created by Heathkit (again this company ceased due gross mismanaged by Zenith Radio Corporation). > > I do not have skill to do with FPGA and VHDL and create soft based MK5017. Perhaps you may have a skill do that. Heathkit GC-1005 schematic is available at many websites for download at no cost. > > The most difficult to find is datasheet for MK5017 until today, I found it. Enclosed the datasheet to help you to create for the FPGA and may need modify the circuit if possible. > > I cannot add file here but if you are interesting and let me know then I can send you the datasheet. Why not post it somewhere on the Internet and then post a link to that site? -- Rick CArticle: 160139
On Mon, 19 Jun 2017 18:09:45 -0700, steven.feinsmith wrote: > Hi Everyone, > > Perhaps you may have a skill to create FPGA and create a clone for 1974 > MOSTEK MK5017, famous clock chip by Heathkit. They used this chip on > model GC-1005 and run with Panaplex display tubes by Sperry Rand. > Unfortunately, MOSTEK went out of business (thanks to US EPA that > destroyed wonderful company by enormous fines instead of help to clean). > > Nowdays, it is impossible to find workable MK5017 (several series)to > handle the circuit created by Heathkit (again this company ceased due > gross mismanaged by Zenith Radio Corporation). > > I do not have skill to do with FPGA and VHDL and create soft based > MK5017. Perhaps you may have a skill do that. Heathkit GC-1005 schematic > is available at many websites for download at no cost. > > The most difficult to find is datasheet for MK5017 until today, I found > it. Enclosed the datasheet to help you to create for the FPGA and may > need modify the circuit if possible. > > I cannot add file here but if you are interesting and let me know then I > can send you the datasheet. > > Thank you very much, > SF I googled for MOSTEK MK5017 and found an app note. The part is PMOS. It runs from high voltages. (Well, high voltages if you are used to FPGAs.) It drives multiplexed fluorescent 7 segment displays. In terms of implementing the functionality, I would recommend a microcontroller instead of an FPGA. Reason: they're cheap and easier to program. Some have RTCs built in. You will need to surround the microcontroller with various high voltage buffers. You could put all that (and a socket for a Li cell so it doesn't lose time when the power is interrupted) on a board that would fit inside the original DIP24 footprint. Regards, AllanArticle: 160140
i am having problem while doing pipeline zbt sram,plzz help if zbt possible give me the zbt sram controller codes....(verilog)....plzz help me i m doing an mtech project still struglling to complete i took 5 yearsArticle: 160141
i m doing project on zbt sram controller....i m having problem in pipeline operation of zbt sram...i took 5 years till now not at completed the project...plzz if u have zbt sram controller working code give me...plzz give ur contact no to disscussArticle: 160142
steven.feinsmith: > Hi Everyone, > > Perhaps you may have a skill to create FPGA and create a clone for 1974 MOSTEK MK5017, famous clock chip by Heathkit. They used this chip on model GC-1005 and run with Panaplex display tubes by Sperry Rand. Unfortunately, MOSTEK went out of business (thanks to US EPA that destroyed wonderful company by enormous fines instead of help to clean). > > Nowdays, it is impossible to find workable MK5017 (several series)to handle the circuit created by Heathkit (again this company ceased due gross mismanaged by Zenith Radio Corporation). > > I do not have skill to do with FPGA and VHDL and create soft based MK5017. Perhaps you may have a skill do that. Heathkit GC-1005 schematic is available at many websites for download at no cost. > > The most difficult to find is datasheet for MK5017 until today, I found it. Enclosed the datasheet to help you to create for the FPGA and may need modify the circuit if possible. > > I cannot add file here but if you are interesting and let me know then I can send you the datasheet. > > Thank you very much, > SF It might be fun to do but I can't see it paying for itself. How many could be sold ? The -30V supply would be tricky to duplicate but certainly possible. MKArticle: 160143
How would you assure safe and efficient reuse of an FPGA design module for= some stand-alone functionality? Let's consider this for a simple example like a UART. Now what would you do= ? You could of course just make lots of functions, procedures, processes and = concurrent statements, - and then include all of this into your FPGA top-le= vel whenever you need a UART... But no serious FPGA designer would ever d= o this. =20 Why? Because we all know it is much better to put all of this into a comp= onent (a VHDL entity), as this has the following benefits: - Everything is encapsulated in an entity containing all needed elements - No risk of forgetting parts or functionality - No need to understand the implementation - A simple port interface for integration into the FPGA top level - A simple generic interface for parameterisation of the module - Internal modifications may be done locally - invisible at the FPGA top le= vel - New functionality may be added inside the encapsulation - Reuse is safe and efficient Now - give me one reason why all of this does not apply to verification exa= ctly the same way. Yes - we could still just use lots of processes, sub-programs, etc, but as = for design that would be very inefficient and risky. What we need is of course a VHDL entity - a VHDL Verification Component (VV= C) - encapsulating the complete verification functionality for a given desi= gn interface, where the VVC should be characterized by: - An easy to understand component interface (ports and generics) - A clearly defined internal functionality, where the internal implementati= on is of no interest when integrating the VVC - An easy to understand command interface to control and monitor the behavi= our of the VVC This is exactly how the VVCs of UVVM (Universal VHDL Verification Methodolo= gy, free and Open source) are made.=20 (For a figure of the UART VVC please see http://bitvis.no/products/uvvm-vvc= -framework/vvc_efficient_reuse/) The VVC for a UART has two simple physical port (TX, RX), and is thus very = easy to integrate in a testbench. All the functionality is included inside = and thus well encapsulated and easy to reuse. Once included in the testbenc= h the test sequencer/driver/controller may then execute commands to transmi= t and receive data in many different ways. This command interface is predef= ined in UVVM, which thus provides a common and standardised way of communic= ating with any VVC independent of type - again just like a CPU may communic= ate with any design module inside an FPGA via a predefined bus interface. A major additional benefit of the UVVM VVCs is the ease of integration, the= very structured internal architecture and the extreme reuse friendliness. UVVM is free and open source, and may be downloaded from Github: https://gi= thub.com/UVVM/UVVM_All For a simple and fast introduction to UVVM and VHDL Verification Components= see: http://bitvis.no/media/21190/UVVM_Advanced_Verif_made_simple_1.pdfArticle: 160144
On Wednesday, 16 September 1998 08:00:00 UTC+1, Stefan Rave wrote: > What is the best choice for use with an XC4000XL FPGA: synchronous or > asynchronous SRAM? What's the advantage of synchronous SRAM, anyway? 1998 ehArticle: 160145
I've been given conflicting device on which language to use. There are people I would consider to be expert professionals who tell me to use VHDL, and others who tell me Verilog. Most everybody tells me that if I use VHDL there's less chance for error, but that it does take more effort to learn. Any thoughts? Thank you, Rick C. HodginArticle: 160146
Rick C. Hodgin wrote on 6/21/2017 8:08 AM: > I've been given conflicting device on which language to use. There > are people I would consider to be expert professionals who tell me > to use VHDL, and others who tell me Verilog. Most everybody tells > me that if I use VHDL there's less chance for error, but that it > does take more effort to learn. > > Any thoughts? I don't recommend one over the other. It's like asking if steak is "better" than Sea Bass. It depends more on the user than the language. Verilog has a lot in common with C. It is more brief to type than VHDL, it allows some things to be implied through defaults rather than specified explicitly and can be much faster to come up to speed with. VHDL is much more verbose, requires *everything* to be indicated explicitly and can be hard to get up to speed with a longer learning curve. When people talk about "less chance for error" they are referring to the strong typing and requirement that everything be explicit. In Verilog you can write code that uses the defaults for type conversions and even things like word size adjustments. So if you aren't familiar with all these defaults it may not do what you were hoping for. In VHDL you don't get to take the shortcuts and *must* convert types and adjust all operands and results to match. Otherwise you get error messages that don't always tell you what you did wrong. Personally I find VHDL to be ok, but that is mostly because I've used it for some 20 years. The only thing holding me back from working in Verilog is no one can recommend a good Verilog book that covers all the pitfalls. I've been told many times that a good Verilog book has yet to be written. If you want to learn both (what I actually recommend) I suggest you learn VHDL first, get good enough at it that you don't swear every time you have to type convert an integer, and only *then* learn Verilog. Then you will have given VHDL a decent chance and you can make your own decision whether Verilog is your preference. I'm pretty sure once you learn Verilog you will find learning VHDL to be very annoying. -- Rick CArticle: 160147
On Wednesday, June 21, 2017 at 11:20:04 AM UTC-4, rickman wrote: > Rick C. Hodgin wrote on 6/21/2017 8:08 AM: > > I've been given conflicting device on which language to use. There > > are people I would consider to be expert professionals who tell me > > to use VHDL, and others who tell me Verilog. Most everybody tells > > me that if I use VHDL there's less chance for error, but that it > > does take more effort to learn. > > > > Any thoughts? > > I don't recommend one over the other. It's like asking if steak is "better" > than Sea Bass. It depends more on the user than the language. > > Verilog has a lot in common with C. It is more brief to type than VHDL, it > allows some things to be implied through defaults rather than specified > explicitly and can be much faster to come up to speed with. VHDL is much > more verbose, requires *everything* to be indicated explicitly and can be > hard to get up to speed with a longer learning curve. > > When people talk about "less chance for error" they are referring to the > strong typing and requirement that everything be explicit. In Verilog you > can write code that uses the defaults for type conversions and even things > like word size adjustments. So if you aren't familiar with all these > defaults it may not do what you were hoping for. In VHDL you don't get to > take the shortcuts and *must* convert types and adjust all operands and > results to match. Otherwise you get error messages that don't always tell > you what you did wrong. > > Personally I find VHDL to be ok, but that is mostly because I've used it for > some 20 years. The only thing holding me back from working in Verilog is no > one can recommend a good Verilog book that covers all the pitfalls. I've > been told many times that a good Verilog book has yet to be written. > > If you want to learn both (what I actually recommend) I suggest you learn > VHDL first, get good enough at it that you don't swear every time you have > to type convert an integer, and only *then* learn Verilog. Then you will > have given VHDL a decent chance and you can make your own decision whether > Verilog is your preference. I'm pretty sure once you learn Verilog you will > find learning VHDL to be very annoying. I've had difficulty with the mechanics of Verilog. I have been able to go through examples on EDA Playground, for example, but there are a handful of things I don't yet understand, and they are hindering me from being able to express ideas into this hardware source code. I have contacted a local group here in Indianapolis, IN, and they have some members with hardware skills. I think they'll be able to help me. One of the members there suggested VHDL well ahead of Verilog. But for now, I'm going to switch to Arduino and at least get my prototypes working, even if they're limited, while I spend my evenings and weekends trying to get the same logic encoded in my FPGA. I appreciate your response. Thank you, Rick C. Thank you, Rick C. HodginArticle: 160148
> Any thoughts? My thought is that you should start with vhdl and ghdl for simulation and g= tkwave for viewing. Or just use Vivado web edition if you want to do things= in a gui. It is not that much of a learning curve with all the example cod= e available on the net. Most of the tricky things with vhdl and types has a= lready been asked at least once, so google will find solutions to just abou= t any problem you may have in the beginning. It is always possible to go to= verilog later if you find that vhdl is not for you. With the good mixed la= nguage support in vivado, you would not waste much of your time learning ei= ther. But I never cared to move to verilog so what do I know. (I do transla= te verilog code to vhdl with icarus or by hand so it is not that I haven't = been exposed to verilog) --=20 SvennArticle: 160149
On 21/06/17 17:20, rickman wrote: > Rick C. Hodgin wrote on 6/21/2017 8:08 AM: >> I've been given conflicting device on which language to use. There >> are people I would consider to be expert professionals who tell me >> to use VHDL, and others who tell me Verilog. Most everybody tells >> me that if I use VHDL there's less chance for error, but that it >> does take more effort to learn. >> >> Any thoughts? > > I don't recommend one over the other. It's like asking if steak is > "better" than Sea Bass. It depends more on the user than the language. > > Verilog has a lot in common with C. It is more brief to type than VHDL, > it allows some things to be implied through defaults rather than > specified explicitly and can be much faster to come up to speed with. > VHDL is much more verbose, requires *everything* to be indicated > explicitly and can be hard to get up to speed with a longer learning curve. > > When people talk about "less chance for error" they are referring to the > strong typing and requirement that everything be explicit. In Verilog > you can write code that uses the defaults for type conversions and even > things like word size adjustments. So if you aren't familiar with all > these defaults it may not do what you were hoping for. In VHDL you > don't get to take the shortcuts and *must* convert types and adjust all > operands and results to match. Otherwise you get error messages that > don't always tell you what you did wrong. > > Personally I find VHDL to be ok, but that is mostly because I've used it > for some 20 years. The only thing holding me back from working in > Verilog is no one can recommend a good Verilog book that covers all the > pitfalls. I've been told many times that a good Verilog book has yet to > be written. > > If you want to learn both (what I actually recommend) I suggest you > learn VHDL first, get good enough at it that you don't swear every time > you have to type convert an integer, and only *then* learn Verilog. > Then you will have given VHDL a decent chance and you can make your own > decision whether Verilog is your preference. I'm pretty sure once you > learn Verilog you will find learning VHDL to be very annoying. > Have you any experience with hardware design languages other than "the big two" ? There are many other possibilities, such as SystemC, SystemVerilog, MyHDL, Lava, etc. I used Confluence for a couple of designs, many years ago - it is a functional programming HDL language. I found it good for making flexible designs with clean synchronous logic, using a fraction of the code needed in Verilog or VHDL for the same job.
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