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 155825

Article: 155825
Subject: Re: timing closure
From: alb <alessandro.basili@cern.ch>
Date: Tue, 24 Sep 2013 10:57:46 +0200
Links: << >>  << T >>  << A >>
Hi Andy,

On 20/09/2013 23:51, jonesandy@comcast.net wrote:
> If you only have one clock frequency, here is a decent starting
> point:

I'm assuming that a system clock and a divided-by-two clock with an
internal PLL are still synchronous under all conditions.

> Synplify has an option to set a default clock frequency and another
> to apply the clock period to all unconstrained IO.
> 
> If you have any IO that need tighter constraints than one clock
> period, you will need to set those up in the constraints manager.

So far I'm using SDC files to setup constraints and let Synplify check
the constraint file. But I'll explore the constraints manager...

> Microsemi also has a good online tutorial for setting up constraints
> for source-synchronous interfaces using virtual clocks.

I'm actually looking up the documentation for the 'SCOPE' tool, even
though I think I will convert it to SDC once everything is ruled out. I
prefer to have physical constraints and timing constraints separate.

> I prefer to set timing constraints in synthesis so that they are
> available for both Synplify and Designer. I do not use the Libero
> front end, only Synplify and Designer.

I use ModelSim, Synplify and Designer separately. I find the Libero
front-end is most of the time in my way... I believe that setting the
time constraints during synthesis allows you to have more control on the
overall margin that can be taken away during P&R.

> If you can avoid them, do not use multi-cycle or false path
> constraints. They are very difficult to verify without much more
> expensive tools. It is way too easy to relax the timing on unintended
> paths with these constraints, and unless you hit just the right
> conditions in a post-P&R simulation, you'll never know it (until
> wierd stuff starts happening in the lab or in the field).

I do not particularly like false paths either, especially because it
would mean extra efforts to exclude them from verification as well...

Article: 155826
Subject: Re: Legal Issues Reproducing Old CPU
From: jg <j.m.granville@gmail.com>
Date: Tue, 24 Sep 2013 17:39:00 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Saturday, September 21, 2013 1:59:18 AM UTC+12, dit...@gmail.com wrote:
>=20
> I will need to reproduce all logical levels into and out of the chip with=
 timing faithful to the original chip (or as close as I can get it, divide =
is going to be an issue). A lot of the circuits on the board are old 54-ser=
ies discrete logic, so those all get sucked in too, so we wind up emulating=
 the tri-state internal to the FPGA. Outside, we have lots of level convert=
ers and discrete control to faithfully replicate the 5V tri-state.
>=20

If you are doing the CPU plus external logic, then you are even safer, as y=
our  end result looks nothing like the original, nor can it drop into an or=
iginal socket.

What Clock Speed, Code and Data memory do you need to have, to match the or=
iginal ?

Article: 155827
Subject: Re: Legal Issues Reproducing Old CPU
From: Walter Banks <walter@bytecraft.com>
Date: Thu, 26 Sep 2013 14:12:04 -0400
Links: << >>  << T >>  << A >>


ditiris@gmail.com wrote:

> Wow, lots of activity since I last checked. To answer some questions:
>
> This is for business, not an educational exercise.
>
> The chip is in the TI 9900 family (weird architecture).
> . .  . .

> However, we're still going to consult with a lawyer just to be sure.

You might try to contact TI directly. I have found that the silicon
companies can be quite co-operative given a some good reasons
why you need to do this. Often helping customers even when they
are not going to gain in future consideration. Hiding from them
until they find you can be messy all round.

A gentle engineering approach perhaps passing the material you
intend to disclose to them past a lawyer to understand pitfalls
will often solve problems like this.

Walter..





Article: 155828
Subject: Re: Legal Issues Reproducing Old CPU
From: David Brown <david@westcontrol.removethisbit.com>
Date: Fri, 27 Sep 2013 09:07:24 +0200
Links: << >>  << T >>  << A >>
On 26/09/13 20:12, Walter Banks wrote:
> 
> 
> ditiris@gmail.com wrote:
> 
>> Wow, lots of activity since I last checked. To answer some questions:
>>
>> This is for business, not an educational exercise.
>>
>> The chip is in the TI 9900 family (weird architecture).
>> . .  . .
> 
>> However, we're still going to consult with a lawyer just to be sure.
> 
> You might try to contact TI directly. I have found that the silicon
> companies can be quite co-operative given a some good reasons
> why you need to do this. Often helping customers even when they
> are not going to gain in future consideration. Hiding from them
> until they find you can be messy all round.
> 
> A gentle engineering approach perhaps passing the material you
> intend to disclose to them past a lawyer to understand pitfalls
> will often solve problems like this.
> 
> Walter..
> 

Almost certainly, TI will be unhelpful here.  To give a proper answer,
they would have to involve their own lawyers to figure out what to say,
and that is simply too expensive for a case like this.  So they will
either say nothing at all, or say "No".  If you are really lucky, you
might get something that implies that they don't care, without actually
saying so directly.

I think, however, that /if/ things get ugly in the future and TI tries
to sue you, then you could point to such an conversation with TI as
evidence that you did your best to do the right thing.



Article: 155829
Subject: Re: Legal Issues Reproducing Old CPU
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Fri, 27 Sep 2013 11:51:47 +0000 (UTC)
Links: << >>  << T >>  << A >>
David Brown <david@westcontrol.removethisbit.com> wrote:

(snip)

> Almost certainly, TI will be unhelpful here.  To give a proper answer,
> they would have to involve their own lawyers to figure out what to say,
> and that is simply too expensive for a case like this.  So they will
> either say nothing at all, or say "No".  If you are really lucky, you
> might get something that implies that they don't care, without actually
> saying so directly.

Note that not all companies are like that. Sun released verilog
code for 64 bit SPARC. You can legally build and sell one.
It seems to be now on the Oracle web site.
 
> I think, however, that /if/ things get ugly in the future and TI tries
> to sue you, then you could point to such an conversation with TI as
> evidence that you did your best to do the right thing.

-- glen

Article: 155830
Subject: Re: Legal Issues Reproducing Old CPU
From: David Brown <david@westcontrol.removethisbit.com>
Date: Fri, 27 Sep 2013 15:32:31 +0200
Links: << >>  << T >>  << A >>
On 27/09/13 13:51, glen herrmannsfeldt wrote:
> David Brown <david@westcontrol.removethisbit.com> wrote:
> 
> (snip)
> 
>> Almost certainly, TI will be unhelpful here.  To give a proper answer,
>> they would have to involve their own lawyers to figure out what to say,
>> and that is simply too expensive for a case like this.  So they will
>> either say nothing at all, or say "No".  If you are really lucky, you
>> might get something that implies that they don't care, without actually
>> saying so directly.
> 
> Note that not all companies are like that. Sun released verilog
> code for 64 bit SPARC. You can legally build and sell one.
> It seems to be now on the Oracle web site.

I don't mean to say that TI are particularly secretive or awkward about
these things.  It's just a matter of economics - a big company is
unlikely to give you permission to copy their IP without first passing
it through the lawyers.  When it is an active decision from the company
- such as with Sun, where they felt it would be a good idea if more
people used SPARCs even if they were not made by Sun - it is worth
calling the lawyers.  When it is a single person asking, with no return
for TI, then doing things legally correctly means quite a lot of time
and money for TI.  While TI staff have always been nice and helpful in
my experience, there is a limit to how much you can expect them to do to
be "nice".

>  
>> I think, however, that /if/ things get ugly in the future and TI tries
>> to sue you, then you could point to such an conversation with TI as
>> evidence that you did your best to do the right thing.
> 
> -- glen
> 


Article: 155831
Subject: Re: Legal Issues Reproducing Old CPU
From: Joe Chisolm <jchisolm6@earthlink.net>
Date: Fri, 27 Sep 2013 09:04:42 -0500
Links: << >>  << T >>  << A >>
On Fri, 20 Sep 2013 12:08:23 -0500, Tim Wescott wrote:

> On Fri, 20 Sep 2013 06:59:18 -0700, ditiris wrote:
> 
>> Wow, lots of activity since I last checked. To answer some questions:
>> 
>> This is for business, not an educational exercise.
>> 
>> The chip is in the TI 9900 family (weird architecture).
>> 
>> I will need to reproduce all logical levels into and out of the chip
>> with timing faithful to the original chip (or as close as I can get it,
>> divide is going to be an issue). A lot of the circuits on the board are
>> old 54-series discrete logic, so those all get sucked in too, so we
>> wind up emulating the tri-state internal to the FPGA. Outside, we have
>> lots of level converters and discrete control to faithfully replicate
>> the 5V tri-state.
>> 
>> The application is real-time, so I think that rules out software
>> emulation. I explored that path a bit, but after reading up on SNES
>> emulators (1991 3.58MHz 16-bit CPU) and finding that most are heavily
>> optimized and largely written in assembly, I figured HDL was a better
>> cost-value-risk proposal. When I got to the part how most software
>> emulators only work most of the time and they actually need a 3GHz
>> multi-core CPU to accurately model the SNES hardware delays in all
>> cases, I was really convinced HDL was the way to go...
>> 
>> Software emulators are apparently fine legally, and I think that's a
>> close corollary to what we'll be doing. Given that Tekmos has a
>> business at all, we should really be fine.
>> 
>> However, we're still going to consult with a lawyer just to be sure.
> 
> Legal problems aside, if there's an emulator out there that's 100%
> accurate but for timing, and if you can do it this way, I'd run it fast
> enough so that the slowest instruction happens on time, then slow all
> the other ones down to match.
> 
> That gets difficult if some execution times are data-dependent.
> 
> As far as actual legal problems -- I think you're OK, but talking to a
> lawyer is a Good Idea.
> 
> First TI would have to care.  Then they'd have to dare.  Your biggest
> problem would be some TI lawyer trying to justify his pay by finding an
> encroachment, and you getting squished long before you can win just
> because they're so much bigger than you.

I agree with Tim on using an emulator if you can.  I do not see why
you need to get down to the gate level.  I have never done
any work with this CPU but a quick search brings up many emulators
for the TI-99 game system that, from what I read, used the TMS9900.
Pull the core cpu emulator code out of one of these and put it in
a fast micro, possibly one that will run out of SRAM.  You can tie
the micro's ISR into the emulator so you get good interrupt timing.
You will still probably have to hang some interface logic around
the micro.

The nice thing about using the emulator is you can get it running on
a PC or even a target micro development board, and get the basic
bugs worked out.

The HDL approach would be a very interesting project and a lot of
fun but I think you are under estimating the level of effort to
take something from OpenCores and get it to production level.

-- 
Chisolm
Republic of Texas

Article: 155832
Subject: Re: Legal Issues Reproducing Old CPU
From: Robert Swindells <rjs@fdy2.co.uk>
Date: Fri, 27 Sep 2013 16:40:42 +0000 (UTC)
Links: << >>  << T >>  << A >>
On Fri, 27 Sep 2013 15:32:31 +0200, David Brown wrote:

> On 27/09/13 13:51, glen herrmannsfeldt wrote:
>> David Brown <david@westcontrol.removethisbit.com> wrote:
>> 
>> (snip)
>> 
>>> Almost certainly, TI will be unhelpful here.  To give a proper answer,
>>> they would have to involve their own lawyers to figure out what to
>>> say,
>>> and that is simply too expensive for a case like this.  So they will
>>> either say nothing at all, or say "No".  If you are really lucky, you
>>> might get something that implies that they don't care, without
>>> actually saying so directly.
>> 
>> Note that not all companies are like that. Sun released verilog code
>> for 64 bit SPARC. You can legally build and sell one.
>> It seems to be now on the Oracle web site.
> 
> I don't mean to say that TI are particularly secretive or awkward about
> these things.  It's just a matter of economics - a big company is
> unlikely to give you permission to copy their IP without first passing
> it through the lawyers.  When it is an active decision from the company
> - such as with Sun, where they felt it would be a good idea if more
> people used SPARCs even if they were not made by Sun - it is worth
> calling the lawyers.  When it is a single person asking, with no return
> for TI, then doing things legally correctly means quite a lot of time
> and money for TI.  While TI staff have always been nice and helpful in
> my experience, there is a limit to how much you can expect them to do to
> be "nice".

TI recently released a lot of code for a slightly newer CPU, I think it
would be worth talking to them about the 9900.

Article: 155833
Subject: good SDC reference
From: peter dudley <padudle@gmail.com>
Date: Fri, 27 Sep 2013 10:25:32 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hello All,

It has been many years since I used the Synopsys Design Constraint (SDC) la=
nguage to apply timing constraints to a logic design.  Right now I am worki=
ng on a preexisting Altera Cyclone 4 FPGA design and I believe that the I/O=
 constraints are not complete.  Unfortunately, my first attempts to constra=
in I/O on the part result in Altera timing reports that are incomprehensibl=
e to me. Some of the clocking schemes in this part are very complicated. I =
think I need to go back to school and really understand SDC.

Can anyone recommend a good "Theory and Practice" document for SDC timing c=
onstraints?

Thank you for any advice.

  Pete Dudley

Article: 155834
Subject: Re: Vivado - Pack I/O Registers?
From: peter dudley <padudle@gmail.com>
Date: Fri, 27 Sep 2013 11:19:48 -0700 (PDT)
Links: << >>  << T >>  << A >>
I'm still looking for this option.  I attended the intro Vivado training yesterday. The instructor told me there was an option under the Synthesis Settings menu but I cannot find it.

I will submit a feature request on the Xilinx WebCase system.

Article: 155835
Subject: Re: Problem in Xilinx xapp1052 DMA PCIE custom flow
From: peter dudley <padudle@gmail.com>
Date: Sat, 28 Sep 2013 05:18:59 -0700 (PDT)
Links: << >>  << T >>  << A >>
Those pcie compile scripts are a little loose but not too complicated.  Look inside to see what it is doing and in what directory it expects that file.

Most important, don't give up.

  Pete

Article: 155836
Subject: Re: VHDL syntheses timestamp
From: peter dudley <padudle@gmail.com>
Date: Sat, 28 Sep 2013 05:36:18 -0700 (PDT)
Links: << >>  << T >>  << A >>
Please listen to Kevin and all the others who recommend good version contro=
l practices with FPGA design. Most of the best version control tools, Subve=
rsion, GIT, etc, are free and open now.  Check in early and check in often.=
 Don't worry about disk space. Disk drive space is essentially free now.

The original question of this thread was about how to get a timestamp or si=
milar unique identifier into each and every compile.  A precompile tcl scri=
pt sounds like a good approach.  It could spit out a little HDL module with=
 the desired info so that it can be read from the fpga by a cpu.

My old company (wisely) tried to make each fpga bitfile uniquely identifiab=
le so that the control software could verify that it is running the right f=
pga at boot time.  It was very difficult to remember to manually edit a bit=
 of HDL just to insert some updated version code.

Software guys often insert the subversion revision code into their compiled=
 software builds.  That is ideal but doesn't work with FPGA's because you d=
on't know if your code works (meets timing, etc) and is releaseable until a=
fter you compile.

    Pete

Article: 155837
Subject: Re: Legal Issues Reproducing Old CPU
From: Michael Engel <cuby.engel@googlemail.com>
Date: Sat, 28 Sep 2013 17:25:55 -0700 (PDT)
Links: << >>  << T >>  << A >>
Am Freitag, 27. September 2013 15:32:31 UTC+2 schrieb David Brown:
[...]
> When it is a single person asking, with no return
> for TI, then doing things legally correctly means quite a lot of time
> and money for TI.  While TI staff have always been nice and helpful in
> my experience, there is a limit to how much you can expect them to do to
> be "nice".

In the case of the MSP430 microcontroller series, TI links to Opencore's openmsp430
implementation from their Open Source Projects wiki page (which at least seems
to be a semi-official resource):

http://processors.wiki.ti.com/index.php/Open_Source_Projects_-_MSP430#OpenMSP430

While the openmsp430 is, of course, an open source project, it has been successfully
used in various commercial projects IIRC (it's also been implemented in an ASIC, so that
doesn't sound quite like a hobby project anymore).

-- Michael

Article: 155838
Subject: Lattice diamond / MachXO2
From: jhallen@TheWorld.com (Joseph H Allen)
Date: Sun, 29 Sep 2013 05:24:24 +0000 (UTC)
Links: << >>  << T >>  << A >>
I've recently discovered that Lattice MachXO2 is quite a nice family of
low-end FPGAs.  I like especially the built-in oscillator (but +/- 5.5% is
not good enough for async serial- +/- 1% would be better) and the built-in
1.2V core linear regulator which allows operation of the chip with 3.3V only
(next generation they should work on an integrated switching regulator).  I
can also wish for more analog peripherals (ADC, comparators, anything I can
find on PIC microcontrollers...).

Anyway, they certainly make the system cost lower when compared with Altera
or Xilinx.

Also nice is the MachXO2 breakout board.  The feature I like is that the
built-in USB programmer chip from FTDI is a dual-function device.  It has
both the JTAG programmer, but also has a USB-to-RS-232 converter which shows
up as a separate USB device in Windows.  I can have a console serial
connection with PuTTY and at the same time have the Lattice Programmer. 
Very nice.

It's been an interesting experience using Lattice Diamond.  I think just a
few minor tweeks would make it a lot more usable:

Dump the whole multiple-implementation within one design concept.  Most
projects are only going to have single implementaton, and I think it's
reasonable to create a new project for a new implementaion (the new project
could use the same source files an existing one to get the same effect as
multiple implementations).  Anyway, this would reduce clutter.

I got confused when trying to change the PULLMODE using the spreadsheet
view.  The problem is that spreadsheet view does not consider the .lpf file
as changed until you actually move off of the cell you just modified.  I
think this is a straight bug.

There is a run-manager which lets you select an implementation and has its
own button for "Run".  When you run this way, the Export Files (like JEDEC
or bitstream files) process is not automatically run.

But then there is the "Process" pulldown on the main menu bar.  This also
has "Run" and "Run All", but they are disabled unless you select something
from the Process pane.  "Run All" does actually run the Export Files
process.

Anyway, it's pointless that there are multiple ways to run.  Again, dump the
multi-implementation stuff and have a single run-all button.

I tried the Reveal logic analyzer, but no luck first time.  After insertion
I can no longer place and route the design with the only error shown as
"Done: error 1".  Even after disabling Reveal (also not obvious how this is
done), the error remains.

-- 
/*  jhallen@world.std.com AB1GO */                        /* Joseph H. Allen */
int a[1817];main(z,p,q,r){for(p=80;q+p-80;p-=2*a[p])for(z=9;z--;)q=3&(r=time(0)
+r*57)/7,q=q?q-1?q-2?1-p%79?-1:0:p%79-77?1:0:p<1659?79:0:p>158?-79:0,q?!a[p+q*2
]?a[p+=a[p+=q]=q]=q:0:0;for(;q++-1817;)printf(q%79?"%c":"%c\n"," #"[!a[q-1]]);}

Article: 155839
Subject: Re: Lattice diamond / MachXO2
From: MK <mk@nospam.co.uk>
Date: Sun, 29 Sep 2013 09:03:52 +0100
Links: << >>  << T >>  << A >>
On 29/09/2013 06:24, Joseph H Allen wrote:
> I've recently discovered that Lattice MachXO2 is quite a nice family of
> low-end FPGAs.  I like especially the built-in oscillator (but +/- 5.5% is
> not good enough for async serial- +/- 1% would be better) and the built-in
> 1.2V core linear regulator which allows operation of the chip with 3.3V only
> (next generation they should work on an integrated switching regulator).  I
> can also wish for more analog peripherals (ADC, comparators, anything I can
> find on PIC microcontrollers...).
>
> Anyway, they certainly make the system cost lower when compared with Altera
> or Xilinx.
>
> Also nice is the MachXO2 breakout board.  The feature I like is that the
> built-in USB programmer chip from FTDI is a dual-function device.  It has
> both the JTAG programmer, but also has a USB-to-RS-232 converter which shows
> up as a separate USB device in Windows.  I can have a console serial
> connection with PuTTY and at the same time have the Lattice Programmer.
> Very nice.
>
> It's been an interesting experience using Lattice Diamond.  I think just a
> few minor tweeks would make it a lot more usable:
>
> Dump the whole multiple-implementation within one design concept.  Most
> projects are only going to have single implementaton, and I think it's
> reasonable to create a new project for a new implementaion (the new project
> could use the same source files an existing one to get the same effect as
> multiple implementations).  Anyway, this would reduce clutter.
>
> I got confused when trying to change the PULLMODE using the spreadsheet
> view.  The problem is that spreadsheet view does not consider the .lpf file
> as changed until you actually move off of the cell you just modified.  I
> think this is a straight bug.
>
> There is a run-manager which lets you select an implementation and has its
> own button for "Run".  When you run this way, the Export Files (like JEDEC
> or bitstream files) process is not automatically run.
>
> But then there is the "Process" pulldown on the main menu bar.  This also
> has "Run" and "Run All", but they are disabled unless you select something
> from the Process pane.  "Run All" does actually run the Export Files
> process.
>
> Anyway, it's pointless that there are multiple ways to run.  Again, dump the
> multi-implementation stuff and have a single run-all button.
>
> I tried the Reveal logic analyzer, but no luck first time.  After insertion
> I can no longer place and route the design with the only error shown as
> "Done: error 1".  Even after disabling Reveal (also not obvious how this is
> done), the error remains.
>
While Diamond is not perfect you should remember that it is intended to 
support the whole range of Lattice FPGAs which includes devices much 
bigger devices than the XO2.
The multiple ways of running get useful when it takes a significant 
amount of time to complete the whole process and you just want to run a 
bit of it.
I haven't had much joy with Reveal.
Don't hold your breath for ADCs - the XO3 (just announced and not 
available for some time) doesn't have any.

Michael Kellett

Article: 155840
Subject: Re: VHDL syntheses timestamp
From: Petter Gustad <newsmailcomp6@gustad.com>
Date: Sun, 29 Sep 2013 12:48:03 +0200
Links: << >>  << T >>  << A >>
peter dudley <padudle@gmail.com> writes:

> The original question of this thread was about how to get a timestamp
> or similar unique identifier into each and every compile. A precompile
> tcl script sounds like a good approach. It could spit out a little HDL
> module with the desired info so that it can be read from the fpga by a
> cpu.

Or you can simply pass a generic/parameter which contains the SHA-1 or
whatever in your synthesis script. 

Another common approach is go generate a MIF file or similar RAM
contents file containing the SHA-1/dirty/passed. Typically this RAM will
act like a ROM (e.g. the write signal is never asserted within the FPGA
logic)

> My old company (wisely) tried to make each fpga bitfile uniquely
> identifiable so that the control software could verify that it is
> running the right fpga at boot time. It was very difficult to remember
> to manually edit a bit of HDL just to insert some updated version
> code.

It's also quite common to use a script to extract the SHA-1 etc. and
insert it automatically.

> Software guys often insert the subversion revision code into their
> compiled software builds. That is ideal but doesn't work with FPGA's
> because you don't know if your code works (meets timing, etc) and is
> releaseable until after you compile.

You can still generate the SHA-1 etc. and keep track if that particular
release meet timing etc. elsewhere. Or if you use the mentioned MIF
approach described above you can use a vendor supplied tool to quickly
update the content of the RAM after build to include the timing
information.

//Petter
-- 
.sig removed by request. 

Article: 155841
Subject: Re: Lattice diamond / MachXO2
From: Gabor <gabor@szakacs.org>
Date: Sun, 29 Sep 2013 12:45:19 -0400
Links: << >>  << T >>  << A >>
On 9/29/2013 1:24 AM, Joseph H Allen wrote:
> I've recently discovered that Lattice MachXO2 is quite a nice family of
> low-end FPGAs.  I like especially the built-in oscillator (but +/- 5.5% is
> not good enough for async serial- +/- 1% would be better) ...
>

I've used a much worse built-in oscillator (from Spartan 6) for async
serial communication.  It turns out that most of the tolerance is due
to process, which won't change for any given device.  So in my
application I made an auto-baud detect FSM and required the host
side to send a capital "U" character with minimum 10 ms gap before
and after it.  This sets (or changes) the baud rate simply due to the
sequence of 1's and 0's.  I've found that even after significant warm
up the link still operates within tolerance.  Requiring the protocol
to occasionally update the baud rate would allow for changes in
temperature if necessary.

-- 
Gabor

Article: 155842
Subject: Re: Legal Issues Reproducing Old CPU
From: Stefan Huebner <stefan@huebner-informationselektronik.de>
Date: Sun, 29 Sep 2013 21:33:26 +0200
Links: << >>  << T >>  << A >>
I - not being a lawyer as well - think that this simple CPU would not 
cause legal problems. CPUs that use microcode probably would - if you 
don't create the microcode part on your own but copy it from, say, a 
BIOS which dynamically updates the genuine chip.

Even conservative copyright fighters should agree that it is kind of 
strange to copyright simple commands like branch if not zero, add a<-a+b 
and so on. Complex math or cipher algorithms in modern CPUs might be 
different.

Asking a lawyer would probably help only the lawyer - I cannot imagine 
many of them have worked intensively on this issue, so they have no 
experience and need to invest many hours - I don't know your local 
rates, but here 200 EUR/h for a specialist would be a bargain. So the 
only advantage is probably that he is used to the topic when you call 
him to defend you in a lawsuit :>



Am 18.09.2013 06:30, schrieb ditiris@gmail.com:
> This might not be the best group to ask, but I figured I would start here. I need to duplicate a 35-year-old CPU. Are there legal ramifications doing this?
>
> For instance on OpenCores they have a partially-compliant C54x DSP core. I assume the partial compliance is in part not to run into licensing issues and have TI sue them. However, I need to duplicate the CPU's instruction set and associated cycle count exactly, so I'm pretty much going to copy the CPU using the existing documentation.
>
> Thanks in advance for the help.
>


Article: 155843
Subject: Re: Lattice diamond / MachXO2
From: jhallen@TheWorld.com (Joseph H Allen)
Date: Mon, 30 Sep 2013 00:15:08 +0000 (UTC)
Links: << >>  << T >>  << A >>
In article <PKqdnUrbYqd0Q9rPnZ2dnUVZ7sydnZ2d@bt.com>,
MK  <mk@nospam.co.uk> wrote:

>While Diamond is not perfect you should remember that it is intended to 
>support the whole range of Lattice FPGAs which includes devices much 
>bigger devices than the XO2.
>The multiple ways of running get useful when it takes a significant 
>amount of time to complete the whole process and you just want to run a 
>bit of it.

I'm spoiled by Quartus-II: it has "revisions", but the feature is completely
hidden unless you select Project=>Revisions.  I use a source code control
system, so having this feature in the FPGA is less necessary for me.

>I haven't had much joy with Reveal.

I'll keep trying it :-)

>Don't hold your breath for ADCs - the
>XO3 (just announced and not available for some time) doesn't have any.

The field is wide open for these features.  Logic is logic, so this could be
something new to compete over.

-- 
/*  jhallen@world.std.com AB1GO */                        /* Joseph H. Allen */
int a[1817];main(z,p,q,r){for(p=80;q+p-80;p-=2*a[p])for(z=9;z--;)q=3&(r=time(0)
+r*57)/7,q=q?q-1?q-2?1-p%79?-1:0:p%79-77?1:0:p<1659?79:0:p>158?-79:0,q?!a[p+q*2
]?a[p+=a[p+=q]=q]=q:0:0;for(;q++-1817;)printf(q%79?"%c":"%c\n"," #"[!a[q-1]]);}

Article: 155844
Subject: Re: Lattice diamond / MachXO2
From: jhallen@TheWorld.com (Joseph H Allen)
Date: Mon, 30 Sep 2013 01:05:41 +0000 (UTC)
Links: << >>  << T >>  << A >>
In article <l29lbh$6qh$1@dont-email.me>, Gabor  <gabor@szakacs.org> wrote:
>On 9/29/2013 1:24 AM, Joseph H Allen wrote:
>> I've recently discovered that Lattice MachXO2 is quite a nice family of
>> low-end FPGAs.  I like especially the built-in oscillator (but +/- 5.5% is
>> not good enough for async serial- +/- 1% would be better) ...
>>
>
>I've used a much worse built-in oscillator (from Spartan 6) for async
>serial communication.  It turns out that most of the tolerance is due
>to process, which won't change for any given device.  So in my
>application I made an auto-baud detect FSM and required the host
>side to send a capital "U" character with minimum 10 ms gap before
>and after it.  This sets (or changes) the baud rate simply due to the
>sequence of 1's and 0's.  I've found that even after significant warm
>up the link still operates within tolerance.  Requiring the protocol
>to occasionally update the baud rate would allow for changes in
>temperature if necessary.

Are you using CFGMCLK? Interesting..  +/- 55%! This seems to be available
starting Virtex-4.

Well I guess you get auto baud rate detection as a side benefit.

-- 
/*  jhallen@world.std.com AB1GO */                        /* Joseph H. Allen */
int a[1817];main(z,p,q,r){for(p=80;q+p-80;p-=2*a[p])for(z=9;z--;)q=3&(r=time(0)
+r*57)/7,q=q?q-1?q-2?1-p%79?-1:0:p%79-77?1:0:p<1659?79:0:p>158?-79:0,q?!a[p+q*2
]?a[p+=a[p+=q]=q]=q:0:0;for(;q++-1817;)printf(q%79?"%c":"%c\n"," #"[!a[q-1]]);}

Article: 155845
Subject: Re: Lattice diamond / MachXO2
From: jg <j.m.granville@gmail.com>
Date: Sun, 29 Sep 2013 18:36:50 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Monday, September 30, 2013 12:15:08 PM UTC+12, Joseph H Allen wrote:
> 
> >Don't hold your breath for ADCs - the
> >XO3 (just announced and not available for some time) doesn't have any.
> 
> The field is wide open for these features.  Logic is logic, so this could be
> something new to compete over.

ADCs are not quite Logic. Harder to get right, and more costly to test.
 
However what they could include, which is just logic, is support for the isolated/separate Sigma-Delta ADC front ends from ADi / Maxim etc.

Article: 155846
Subject: Re: Lattice diamond / MachXO2
From: GaborSzakacs <gabor@alacron.com>
Date: Mon, 30 Sep 2013 10:36:12 -0400
Links: << >>  << T >>  << A >>
Joseph H Allen wrote:
> In article <l29lbh$6qh$1@dont-email.me>, Gabor  <gabor@szakacs.org> wrote:
>> On 9/29/2013 1:24 AM, Joseph H Allen wrote:
>>> I've recently discovered that Lattice MachXO2 is quite a nice family of
>>> low-end FPGAs.  I like especially the built-in oscillator (but +/- 5.5% is
>>> not good enough for async serial- +/- 1% would be better) ...
>>>
>> I've used a much worse built-in oscillator (from Spartan 6) for async
>> serial communication.  It turns out that most of the tolerance is due
>> to process, which won't change for any given device.  So in my
>> application I made an auto-baud detect FSM and required the host
>> side to send a capital "U" character with minimum 10 ms gap before
>> and after it.  This sets (or changes) the baud rate simply due to the
>> sequence of 1's and 0's.  I've found that even after significant warm
>> up the link still operates within tolerance.  Requiring the protocol
>> to occasionally update the baud rate would allow for changes in
>> temperature if necessary.
> 
> Are you using CFGMCLK? Interesting..  +/- 55%! This seems to be available
> starting Virtex-4.

Exactly.  I was pleasantly surprised at the low temperature drift in the
Spartan 6, especially given the huge range over PVT.  As I said it
appears that Process gives the lion's share of the 55%.

> 
> Well I guess you get auto baud rate detection as a side benefit.
> 

In my case this came by necessity.  I was using an external SiLabs
clock generator that needed to be programmed via I2C in order to get
any clocks to the FPGA.  Once that is up and running, I've got some
very precise clocks to use.  Unfortunately the settings for the
SiLabs chip get uploaded from a COM port, so I needed to have some
way to bootstrap the system.  The internal clock, bad as it is, saved me
the expense of an additional clock oscillator.  It also gives me
a way to operate I2C, even when I already have the settings uploaded.
The SiLabs chip stops outputting clocks while it is re-preogrammed.
Of course an I2C master does not need a precise clock.

-- 
Gabor

Article: 155847
Subject: Re: Lattice diamond / MachXO2
From: rickman <gnuarm@gmail.com>
Date: Mon, 30 Sep 2013 11:50:59 -0400
Links: << >>  << T >>  << A >>
On 9/30/2013 10:36 AM, GaborSzakacs wrote:
>
> In my case this came by necessity. I was using an external SiLabs
> clock generator that needed to be programmed via I2C in order to get
> any clocks to the FPGA. Once that is up and running, I've got some
> very precise clocks to use. Unfortunately the settings for the
> SiLabs chip get uploaded from a COM port, so I needed to have some
> way to bootstrap the system. The internal clock, bad as it is, saved me
> the expense of an additional clock oscillator. It also gives me
> a way to operate I2C, even when I already have the settings uploaded.
> The SiLabs chip stops outputting clocks while it is re-preogrammed.
> Of course an I2C master does not need a precise clock.

Couldn't you have just used some default settings for the clock chip 
which would give you a workable baud rate, then update the settings from 
the com port?

-- 

Rick

Article: 155848
Subject: Re: Lattice diamond / MachXO2
From: jhallen@TheWorld.com (Joseph H Allen)
Date: Mon, 30 Sep 2013 18:34:26 +0000 (UTC)
Links: << >>  << T >>  << A >>
In article <l2afqc$679$1@pcls7.std.com>,
Joseph H Allen <jhallen@TheWorld.com> wrote:
>In article <PKqdnUrbYqd0Q9rPnZ2dnUVZ7sydnZ2d@bt.com>,
>MK  <mk@nospam.co.uk> wrote:

>>I haven't had much joy with Reveal.

>I'll keep trying it :-)

I did get it to work.  One gotcha is that your clock (the sample clock for
reveal) must be faster than the JTAG clock.  I'm not really sure what
frequency the JTAG clock is, but faster than 7 MHz but slower than 66.5 MHz.

Second is the error return mystery from par.  Par completed, but GUI said it
had an error.  Even with the error return the GUI proceded with bitgen if I
asked it to.  The GUI is definitely rough..  I also experienced some more
glitches with the spreadsheet view.
-- 
/*  jhallen@world.std.com AB1GO */                        /* Joseph H. Allen */
int a[1817];main(z,p,q,r){for(p=80;q+p-80;p-=2*a[p])for(z=9;z--;)q=3&(r=time(0)
+r*57)/7,q=q?q-1?q-2?1-p%79?-1:0:p%79-77?1:0:p<1659?79:0:p>158?-79:0,q?!a[p+q*2
]?a[p+=a[p+=q]=q]=q:0:0;for(;q++-1817;)printf(q%79?"%c":"%c\n"," #"[!a[q-1]]);}

Article: 155849
Subject: Re: Lattice diamond / MachXO2
From: GaborSzakacs <gabor@alacron.com>
Date: Mon, 30 Sep 2013 15:28:34 -0400
Links: << >>  << T >>  << A >>
rickman wrote:
> On 9/30/2013 10:36 AM, GaborSzakacs wrote:
>>
>> In my case this came by necessity. I was using an external SiLabs
>> clock generator that needed to be programmed via I2C in order to get
>> any clocks to the FPGA. Once that is up and running, I've got some
>> very precise clocks to use. Unfortunately the settings for the
>> SiLabs chip get uploaded from a COM port, so I needed to have some
>> way to bootstrap the system. The internal clock, bad as it is, saved me
>> the expense of an additional clock oscillator. It also gives me
>> a way to operate I2C, even when I already have the settings uploaded.
>> The SiLabs chip stops outputting clocks while it is re-preogrammed.
>> Of course an I2C master does not need a precise clock.
> 
> Couldn't you have just used some default settings for the clock chip 
> which would give you a workable baud rate, then update the settings from 
> the com port?
> 

I could, but the settings for this particular chip would eat up a block
RAM if I stored them internal to the FPGA.  So I placed them in the
attached SPI flash along with other general device settings.  I could
also pre-program the SPI flash but it's generally easier for
manufactufing to upload everything starting from blank parts.  Once
the unit has settings uploaded, it can come up running on the next
power cycle.  I still keep the communication port working from the
internal oscillator because it's easier than switching clocks, though.
I do have code that calibrates the baud divisor when the external clocks
are running.  Still it wasn't too much of a hardship to require the
auto-baud startup in the protocol from the PC host.

At one time I was generating MCS files for the device that contained
both the FPGA bitstream and the settings, but it turns out that Impact
is very slow and stupid about programming the SPI flash when there
are big gaps between individual files, so the self-programming with
upload from a 115,200 baud COM port was actually faster.  Now we only
use JTAG for the initial FPGA bitstream, and all subsequent updates
are done via the COM port, including FPGA bitstream updates.

-- 
Gabor



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