Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMar2019

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

Custom Search

Messages from 160125

Article: 160125
Subject: Re: Article about using Non-Project Mode
From: Kevin Neilson <kevin.neilson@xilinx.com>
Date: Sat, 10 Jun 2017 13:42:42 -0700 (PDT)
Links: << >>  << T >>  << A >>
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
Subject: Re: Article about using Non-Project Mode
From: Ilya Kalistru <stebanoid@gmail.com>
Date: Sat, 10 Jun 2017 23:34:57 -0700 (PDT)
Links: << >>  << T >>  << A >>
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
Subject: Re: Article about using Non-Project Mode
From: Theo Markettos <theom+news@chiark.greenend.org.uk>
Date: 12 Jun 2017 11:02:49 +0100 (BST)
Links: << >>  << T >>  << A >>
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)

Theo

Article: 160128
Subject: Re: Article about using Non-Project Mode
From: Ilya Kalistru <stebanoid@gmail.com>
Date: Mon, 12 Jun 2017 10:40:28 -0700 (PDT)
Links: << >>  << T >>  << A >>
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
Subject: Re: Article about using Non-Project Mode
From: Rob Gaddi <rgaddi@highlandtechnology.invalid>
Date: Mon, 12 Jun 2017 10:47:30 -0700
Links: << >>  << T >>  << A >>
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
Subject: Re: Article about using Non-Project Mode
From: Ilya Kalistru <stebanoid@gmail.com>
Date: Tue, 13 Jun 2017 11:31:56 -0700 (PDT)
Links: << >>  << T >>  << A >>
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
Subject: Whups. Lattice Diamond says my package does not exist.
From: len.turnbow@gmail.com
Date: Thu, 15 Jun 2017 21:40:56 -0700 (PDT)
Links: << >>  << T >>  << A >>
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!

--Len

Article: 160132
Subject: Re: Whups. Lattice Diamond says my package does not exist.
From: rickman <gnuarm@gmail.com>
Date: Fri, 16 Jun 2017 02:12:27 -0400
Links: << >>  << T >>  << A >>
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 C

Article: 160133
Subject: Re: Whups. Lattice Diamond says my package does not exist.
From: len.turnbow@gmail.com
Date: Thu, 15 Jun 2017 23:44:28 -0700 (PDT)
Links: << >>  << T >>  << A >>
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!
 --Len

Article: 160134
Subject: Re: Whups. Lattice Diamond says my package does not exist.
From: Cecil Bayona <cbayona@cbayona.com>
Date: Fri, 16 Jun 2017 11:29:29 -0500
Links: << >>  << T >>  << A >>
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 - k5nwa

Article: 160135
Subject: Re: Whups. Lattice Diamond says my package does not exist.
From: rickman <gnuarm@gmail.com>
Date: Fri, 16 Jun 2017 12:43:18 -0400
Links: << >>  << T >>  << A >>
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 C

Article: 160136
Subject: Re: Whups. Lattice Diamond says my package does not exist.
From: Jon Elson <jmelson@wustl.edu>
Date: Fri, 16 Jun 2017 13:20:48 -0500
Links: << >>  << T >>  << A >>
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.

Jon

Article: 160137
Subject: Create FPGA to replace 1974 MOSTEK MK5017
From: steven.feinsmith@gmail.com
Date: Mon, 19 Jun 2017 18:09:45 -0700 (PDT)
Links: << >>  << T >>  << A >>
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,
SF

Article: 160138
Subject: Re: Create FPGA to replace 1974 MOSTEK MK5017
From: rickman <gnuarm@gmail.com>
Date: Mon, 19 Jun 2017 23:18:21 -0400
Links: << >>  << T >>  << A >>
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 C

Article: 160139
Subject: Re: Create FPGA to replace 1974 MOSTEK MK5017
From: Allan Herriman <allanherriman@hotmail.com>
Date: 20 Jun 2017 09:21:46 GMT
Links: << >>  << T >>  << A >>
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,
Allan

Article: 160140
Subject: Re: sync or async SRAM?
From: lakshmangowda3391@gmail.com
Date: Tue, 20 Jun 2017 04:36:18 -0700 (PDT)
Links: << >>  << T >>  << A >>
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 years

Article: 160141
Subject: Re: sync or async SRAM?
From: lakshmangowda3391@gmail.com
Date: Tue, 20 Jun 2017 04:39:20 -0700 (PDT)
Links: << >>  << T >>  << A >>
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 disscuss

Article: 160142
Subject: Re: Create FPGA to replace 1974 MOSTEK MK5017
From: "Michael Kellett" <nospam@invalid.com>
Date: tue, 20 jun 2017 13:37:31 +0100
Links: << >>  << T >>  << A >>
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.

MK

Article: 160143
Subject: =?UTF-8?Q?VHDL_Verification_components_=E2=80=93_The_obvious_solutio?=
From: Espen Tallaksen <espen.tallaksen@bitvis.no>
Date: Wed, 21 Jun 2017 00:05:14 -0700 (PDT)
Links: << >>  << T >>  << A >>
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.pdf


Article: 160144
Subject: Re: sync or async SRAM?
From: edmoore <edmoore1966@googlemail.com>
Date: Wed, 21 Jun 2017 01:34:26 -0700 (PDT)
Links: << >>  << T >>  << A >>
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 eh

Article: 160145
Subject: VHDL or Verilog?
From: "Rick C. Hodgin" <rick.c.hodgin@gmail.com>
Date: Wed, 21 Jun 2017 05:08:46 -0700 (PDT)
Links: << >>  << T >>  << A >>
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. Hodgin

Article: 160146
Subject: Re: VHDL or Verilog?
From: rickman <gnuarm@gmail.com>
Date: Wed, 21 Jun 2017 11:20:01 -0400
Links: << >>  << T >>  << A >>
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 C

Article: 160147
Subject: Re: VHDL or Verilog?
From: "Rick C. Hodgin" <rick.c.hodgin@gmail.com>
Date: Wed, 21 Jun 2017 08:27:26 -0700 (PDT)
Links: << >>  << T >>  << A >>
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. Hodgin

Article: 160148
Subject: Re: VHDL or Verilog?
From: Svenn Are Bjerkem <svenn.bjerkem@gmail.com>
Date: Wed, 21 Jun 2017 08:47:31 -0700 (PDT)
Links: << >>  << T >>  << A >>
> 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
Svenn

Article: 160149
Subject: Re: VHDL or Verilog?
From: David Brown <david.brown@hesbynett.no>
Date: Wed, 21 Jun 2017 19:36:43 +0200
Links: << >>  << T >>  << A >>
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:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMar2019

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

Custom Search