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
2017JanFebMarApr2017

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 159300

Article: 159300
Subject: Re: requirement for PC for VHDL design
From: Theo Markettos <theom+news@chiark.greenend.org.uk>
Date: 27 Sep 2016 07:18:10 +0100 (BST)
Links: << >>  << T >>  << A >>
David Brown <david.brown@hesbynett.no> wrote:
> What sort of sizes are you talking about for these files?

The total size of files touched is of the order of gigabytes.
 
> If you have enough ram, so that they are in your disk caches, then disk
> latency will be pretty much irrelevant.  When the app writes the files,
> they go into cache - the actual write to disk takes place asynchronously
> unless the app specifically waits for it - the delay before hitting the
> disk surface does not matter.  When the app reads the files, they are
> already in cache and the data is returned immediately.  (This is on
> Linux - Windows tends to wait for files to be written out, then might
> clear them from cache so that they must be re-read later.)

That doesn't help if you're touching the file for the first time.  In the
case of building collections of IP you scan the library files (lots of small
verilog files) which means lots of small reads of disparate files.

Bear in mind that FPGA builds are long enough that the files may go into the
cache, but they aren't there when your build completes after an hour and you
start a new build.  On 16GB-class desktops/laptops there's enough going on
that the cache probably doesn't stick around long enough.

Theo

Article: 159301
Subject: Re: requirement for PC for VHDL design
From: David Brown <david.brown@hesbynett.no>
Date: Tue, 27 Sep 2016 09:12:09 +0200
Links: << >>  << T >>  << A >>
On 27/09/16 08:18, Theo Markettos wrote:
> David Brown <david.brown@hesbynett.no> wrote:
>> What sort of sizes are you talking about for these files?
> 
> The total size of files touched is of the order of gigabytes.
>  
>> If you have enough ram, so that they are in your disk caches, then disk
>> latency will be pretty much irrelevant.  When the app writes the files,
>> they go into cache - the actual write to disk takes place asynchronously
>> unless the app specifically waits for it - the delay before hitting the
>> disk surface does not matter.  When the app reads the files, they are
>> already in cache and the data is returned immediately.  (This is on
>> Linux - Windows tends to wait for files to be written out, then might
>> clear them from cache so that they must be re-read later.)
> 
> That doesn't help if you're touching the file for the first time.  In the
> case of building collections of IP you scan the library files (lots of small
> verilog files) which means lots of small reads of disparate files.

That is true, for the first time you read them (after booting, or waking
from sleep).  Thereafter the files are in the cache.

> 
> Bear in mind that FPGA builds are long enough that the files may go into the
> cache, but they aren't there when your build completes after an hour and you
> start a new build.  On 16GB-class desktops/laptops there's enough going on
> that the cache probably doesn't stick around long enough.

The key here is to have enough memory so that this does not happen.
That is a challenge on a laptop, because you seldom get lots of memory -
but on a desktop/workstation for FPGA design, 24 GB or 32 GB is not
going to be unreasonable (32 GB is a similar price to a reasonable SSD).

> 
> Theo
> 


Article: 159302
Subject: Sharing a single Lookup Table
From: Marvin L <user123random@gmail.com>
Date: Tue, 27 Sep 2016 18:31:41 -0700 (PDT)
Links: << >>  << T >>  << A >>
I am implementing the gamma correction LUT as in https://ptpb.pw/ZwYS

if I want to share a single combinatorial lookup table with multiple input, it is not possible, right ?

because in this case, the lookup table would just assign to one output reg

say all r, g and b channels want to use the same combinatorial lookup table, how would I do it ?

Someone suggested the following, could anyone advice ?
mux -> lut -> demux


But my friend told me the following instead:
A 256-sized table can be done in one slice, containing 4-luts--for every output bit.  It will consume all 4 luts of the slice.

So ... we're talking about 8 slices, or 32-luts, per color.

96 LUTs is reasonable.  Now, if you wished to somehow re-use those 96 LUTs to get your logic down to a smaller size, be prepared for the fact that it will cost logic to make any logic change--perhaps as much as the 96 LUTs that you would originally need.

Article: 159303
Subject: Re: requirement for PC for VHDL design
From: Theo Markettos <theom+news@chiark.greenend.org.uk>
Date: 28 Sep 2016 07:43:55 +0100 (BST)
Links: << >>  << T >>  << A >>
kristoff <kristoff@skypro.be> wrote:
> Well, what got me thinking is the fact that my employer now has a 
> project with HP which includes an additional reduction on the price, but 
> -in the other hand- really limits my choice.
> 
> As I work about 120 km from where I live for 3 days in a week, I am more 
> interested in a laptop with a limited screen-size as I do need to carry 
> the thing on the train and in my backpack every day).
> 
> I do have a large external screen at home.

Do you work on the train?  Or is the requirement simply for portability?

One of our remote workers uses a Skull Canyon NUC.  This has an i7 with
EDRAM so is reasonably quick a Quartus compiles.  It's about 5% off the best
out there (the i7-5775c) - the EDRAM is shared with the GPU and there's no
way to plug in an external GPU.  It's a 'portable desktop' rather than a
laptop - he has a second power supply, so just needs to carry the NUC around
and plug it into power, USB and monitor in each place.  Intel have put a lot
of effort into the cooling solution for such a small package - it's not a
95W desktop, but performance is pretty close.

One possible advantage of the NUC is you can point at it and say 'HP don't
sell anything like that' which might work around purchasing requirements.

Otherwise I'd suggest looking at graphics workstation laptops (eg Xeon).
I'm not familiar with what HP have, but likely small and light they aren't.

Theo

Article: 159304
Subject: C to FPGA
From: "Rick C. Hodgin" <rick.c.hodgin@gmail.com>
Date: Thu, 29 Sep 2016 17:39:34 -0700 (PDT)
Links: << >>  << T >>  << A >>
An interesting video:

    C to FPGA Compilation and Domain-Specific Computing
    https://www.youtube.com/watch? v=TNF8EhKDM1c

A tool stack taking C and C variants to FPGA, along with some
findings on different approaches, and at different speed
targets in optimization. Very little concern over power budgets
in their current implementation, but consideration in the
future by additional optimization and / or customization.

Best regards,
Rick C. Hodgin

Article: 159305
Subject: Re: Sharing a single Lookup Table
From: Kevin Neilson <kevin.neilson@xilinx.com>
Date: Fri, 30 Sep 2016 11:43:10 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Tuesday, September 27, 2016 at 7:31:56 PM UTC-6, Marvin L wrote:
> I am implementing the gamma correction LUT as in https://ptpb.pw/ZwYS
>=20
> if I want to share a single combinatorial lookup table with multiple inpu=
t, it is not possible, right ?
>=20
> because in this case, the lookup table would just assign to one output re=
g
>=20
> say all r, g and b channels want to use the same combinatorial lookup tab=
le, how would I do it ?
>=20

You can share a blockRAM-based lookup table between two users.  A LUT-ram-b=
ased lookup can't be shared unless you timeslice it.  Yes, you can do a 256=
->1 lookup in one Virtex-7 slice (using 4 LUTs, 2 F7, and 1 F8 mux).

I looked at your function and it doesn't look like you can use a lookup tab=
le.  There is a 3x3 matrix multiplication so the output is a function of R,=
 G, and B, so if you wanted to do a lookup the table would have to be 3-dim=
ensional and have 256^3 elements.  I think you actually have to implement t=
he logic in this case.  Because the R,G,B inputs are only 8 bits each, you =
can still implement the multiplications in 256-deep lookup tables, but you'=
d still need to sum the results together to get the result of the matrix mu=
lt.

Article: 159306
Subject: Re: C to FPGA
From: Kevin Neilson <kevin.neilson@xilinx.com>
Date: Fri, 30 Sep 2016 11:52:29 -0700 (PDT)
Links: << >>  << T >>  << A >>
>=20
>     C to FPGA Compilation and Domain-Specific Computing
>     https://www.youtube.com/watch? v=3DTNF8EhKDM1c
>=20
> A tool stack taking C and C variants to FPGA,=20

In the video he notes that he had to rewrite the inner loops at a low level=
 to optimize them for hardware synthesis.  This is a characteristic of all =
of these tools:  you rewrite it in very low-level code to get it to work we=
ll in hardware.  Guess what?  You are now doing hardware engineering.  You'=
ve gained absolutely nothing.

Article: 159307
Subject: Re: C to FPGA
From: "Rick C. Hodgin" <rick.c.hodgin@gmail.com>
Date: Fri, 30 Sep 2016 12:55:38 -0700 (PDT)
Links: << >>  << T >>  << A >>
Kevin Neilson wrote:
> In the video he notes that he had to rewrite the inner loops at
> a low level to optimize them for hardware synthesis. This is a
> characteristic of all of these tools: you rewrite it in very low-level
> code to get it to work well in hardware.

What was the mm:ss?  I'd like to put his note in context.

Best regards,
Rick C. Hodgin

Article: 159308
Subject: Re: C to FPGA
From: "Rick C. Hodgin" <rick.c.hodgin@gmail.com>
Date: Sat, 1 Oct 2016 17:31:56 -0700 (PDT)
Links: << >>  << T >>  << A >>
Rick C. Hodgin wrote:
> Kevin Neilson wrote:
> > In the video he notes that he had to rewrite the inner loops at
> > a low level to optimize them for hardware synthesis. This is a
> > characteristic of all of these tools: you rewrite it in very low-level
> > code to get it to work well in hardware.
>
> What was the mm:ss? I'd like to put his note in context.

I watched it again.  The toolset is able to take unaltered C code, or
System C code, and process it through.  An MPEG-4 example showed
a target achieved of 30 fps on unaltered code.

The considerations regarding optimization allow for various targets.
For some high speed throughput goals the target is not achievable
through the toolset due to hardware use limitations on logic
units or work per clock.  In those cases rewriting C algorithms to lower-
level ops can then coax the toolset to produce a solution for your
RTL needs.  It's an enabler for higher speed goals, but, it is not
required in general to produce a workable model for FPGA or
ASIC.

Best regards,
Rick C. Hodgin

Article: 159309
Subject: Re: C to FPGA
From: "Rick C. Hodgin" <rick.c.hodgin@gmail.com>
Date: Sat, 1 Oct 2016 17:40:21 -0700 (PDT)
Links: << >>  << T >>  << A >>
At about 35 minutes or so he also talks about a startup company
that licensed the toolset for commercial use.  The presenter
said they have expanded the toolset into C++.  They are former
students of his.

Best regards,
Rick C. Hodgin

Article: 159310
Subject: Re: learning verilog (or VHDL (or even MyHDL))
From: Jan Coombs <jenfhaomndgfwutc@murmic.plus.com>
Date: Sun, 2 Oct 2016 12:50:04 +0100
Links: << >>  << T >>  << A >>
On Mon, 26 Sep 2016 21:29:21 +0200
kristoff <kristoff@skypro.be> wrote:
> On 26-09-16 21:12, Jan Coombs wrote:
> > Probably only you will know whether you prefer to write every
> > thing in triplicate, or fall between the stepping stones.
> 
> Well, my first interest is to understand the code written by
> others in the many open-source projects out there.

I've done a lot of that, good for getting comfortable with RTL
and other novel aspects of hardware design.  You did shake my
belief expressed in my intuitive comment above, so I checked a
project, and attached a summary below; the VHDL exported is
almost double the size of the verilog.  

> > Alternatively, if you model in MyHDL [1] it can export
> > either, or even both.
> 
> Isn't it best first to learn (or at least to understand) the
> two "main" languages and then move on to the alternatives?

Its not like English vs Chinese!  Whether you prefer the terse
or verbose, the underlying RTL is what you need to grok. My
preference is the less extreme choice, MyHDL.  

MyHDL is a fast[2] free modelling tool, with substantial support
of Python libraries for design and test, and exports to waveform
viewer. Downside: you need good testing to prove design source
is valid and interpreted correctly[3]. Upside: you should be
doing this anyway! 

As for writing Verilog/MyHDL/VHDL,  use code templates, your own
or from net or tool manuals.  Enjoy the trip, this low-level
stuff still fascinates me. 

Jan Coombs
-- 
[1] myhdl.org
[2] http://old.myhdl.org/doku.php/performance
[3] http://docs.myhdl.org/en/stable/manual/unittest.html



#       Sample_DesStruct.utxt

2014-11-08 jc Check imports, update to ...


Project source code tree:

   kB   LoC   Idx 
   --   ---   --- 
  7.0   170   1   
  1.9    50   1.1 
  5.1   116   1.2 
  5.2   139   1.3 
  6.9   180   1.3.1 
 10.0   265   1.4   
  4.1    60   1.4.1 
  2.2    90   1.4.2 
  4.3   102   1.5   
  5.3   156   1.5.1 
  1.6    60   1.4.1.1 
  1.5    60   1.5.1.2 
 17.0   436   1.5.2   
  2.3    90   1.5.2.1 
 14.1   333   1.5.3   
  6.7   161   1.5.3.1 
  9.7   246   1.5.4   
 ----  ----
104.9  2794


Full Project Exports for Synthesis:
  
   kB   LoC   
   --   ---  
 94.1  2714   MyProj.v

173.9  2813   MyProj.vhd + 3k4B library


Notes:

Exported files contain block header comments only, the comment
sizes are identical:

   kB   LoC   
   --   ---  
  6.0   164   MyProj_NoCode.v
  6.0   164   MyProj_NoCode.vhd

Source file code style is more compact than exports, and uses 2
space tabs, exports use 4 space tabs.  


Hardware fabric after synthesis: 

  609 LUT4+FFs  3 RAMs


Article: 159311
Subject: Re: learning verilog
From: thomas.entner99@gmail.com
Date: Sun, 2 Oct 2016 07:09:05 -0700 (PDT)
Links: << >>  << T >>  << A >>
> Some have a quite strong=20
> opinion that Verilog is much more productive and useful.  I won't argue=
=20
> about it until I learn Verilog better.

Simply speaking:
Verilog compiles every piece of code, VHDL compiles none...

VHDL does very strong type checking and also has a verbose syntax which is =
quite cumbersome, but at least, when the compiler does not complain, chance=
s are high that the code does what the designer intended.

Two hints:
- Make use of some VHDL-2008 features (like process(all))
- Understand that you do not need component declarations, you can use
  inst: entity work.foobar(rtl) port map (...)
  without component statement.

Verilog will save you some time writing code but can result in extremely ha=
rd to find errors that turn out to be simply typos. At least a good editor =
is a must and I would suggest to read this: http://www.lcdm-eng.com/papers/=
snug06_Verilog%20Gotchas%20Part1.pdf

Can't comment on MyHDL and SystemVerilog...

Regards,

Thomas

www.entner-electronics.com - Home of EEBlaster and JPEG-Codec

Article: 159312
Subject: Re: PALCE22v10 / GAL22v10 programming algorithms ... Found?
From: Jan Coombs <jenfhaomndgfwutc@murmic.plus.com>
Date: Sun, 2 Oct 2016 15:46:05 +0100
Links: << >>  << T >>  << A >>
On Fri, 2 Sep 2016 13:53:25 -0700 (PDT)
thomas.entner99@gmail.com wrote:

> In my youth I tried to build a GAL programmer, but I never got
> it to work with the samples I had.

Youth, thats the bit I missed out on, I was a mature student
then I did the EPLD work. 

> Later I found out that there appeared to be quite different
> programming algorithms for different parts with the same name,
> so be aware...

I did have the (NDA) programming documents from LatticeSemi and
Intel for these parts, and seem to remember that the Lattice
programming algorithms were not complete in the regular chip
documentation.  


While moving Lattice tools around I noticed that here:

/home/.../Diamond/IspVMsystem/isptools/ispvmsystem/Database/ee9/22v10a/
 
are these files:

  ispgal22v10avp28_spi_loader.jed
  ispgal22v10avq32_spi_loader.jed
  ispVM_005b.xdf

Perhaps some of the tools do still exist?

> Thomas

Jan Coombs
-- 


Article: 159313
Subject: Re: learning verilog
From: rickman <gnuarm@gmail.com>
Date: Sun, 2 Oct 2016 23:05:12 -0400
Links: << >>  << T >>  << A >>
On 10/2/2016 10:09 AM, thomas.entner99@gmail.com wrote:
>> Some have a quite strong opinion that Verilog is much more
>> productive and useful.  I won't argue about it until I learn
>> Verilog better.
>
> Simply speaking: Verilog compiles every piece of code, VHDL compiles
> none...
>
> VHDL does very strong type checking and also has a verbose syntax
> which is quite cumbersome, but at least, when the compiler does not
> complain, chances are high that the code does what the designer
> intended.

Yes, that is the point of strong typing.  It should eliminate the class 
of errors that are due to mistakes in cross type assignments.  This is 
something that you have to understand very thoroughly in order to use 
Verilog because it won't warn you, it will just do something that may or 
may not be what you want.

This is where I am not sure which is preferable.  I can write VHDL code 
easily in spite of the "verboseness" of the language.  I have yet to 
even find a good book that tells you how to deal with these issues in 
Verilog.  I have asked about a good book to learn these issues from an 
have been told in the Verilog group that there is none.  Until I can 
learn about this and be certain I am writing good code, I can't really 
consider using Verilog professionally.


> Two hints: - Make use of some VHDL-2008 features (like process(all))
> - Understand that you do not need component declarations, you can
> use inst: entity work.foobar(rtl) port map (...) without component
> statement.
>
> Verilog will save you some time writing code but can result in
> extremely hard to find errors that turn out to be simply typos. At
> least a good editor is a must and I would suggest to read this:
> http://www.lcdm-eng.com/papers/snug06_Verilog%20Gotchas%20Part1.pdf

Wow.  This is a pretty long paper about "gotchas" in Verilog... 63 
pages!  I'm not sure I want to work with it.

-- 

Rick C

Article: 159314
Subject: Re: learning verilog
From: Tom Gardner <spamjunk@blueyonder.co.uk>
Date: Mon, 3 Oct 2016 09:16:58 +0100
Links: << >>  << T >>  << A >>
On 03/10/16 04:05, rickman wrote:
> On 10/2/2016 10:09 AM, thomas.entner99@gmail.com wrote:
>> Verilog will save you some time writing code but can result in
>> extremely hard to find errors that turn out to be simply typos. At
>> least a good editor is a must and I would suggest to read this:
>> http://www.lcdm-eng.com/papers/snug06_Verilog%20Gotchas%20Part1.pdf
>
> Wow.  This is a pretty long paper about "gotchas" in Verilog... 63 pages!  I'm
> not sure I want to work with it.

How about C/C++? There are many discussions their
"characteristics"; I like the wryly amusing FQA
http://yosefk.com/c++fqa/

Having first used C in 1981 (gulp), I now feel uncomfortable
using it for anything more than a hack. Can you "cast away
constness" at the moment? I remember reading endless discussions
in the early 90s about whether it should be allowed or forbidden
in the standard.

Article: 159315
Subject: Re: ANN: Amontec JTAGkey programs XC4VLX25 at 2.8s
From: jeffrey.thia@gmail.com
Date: Mon, 3 Oct 2016 22:10:40 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hi,

Not sure if this forum is still alive but I am using Amontec JTAGKey2 and t=
he Amontec SVF player to program a Virtex-7 Eval board. The svf player got =
to "SVF Playing File:" and then I got an error message:

"Error code =3D 524 (Line: 0 Error 524: parser_svf -> File not found.)"

What gives? Where do I get this parser_svf file?

On Thursday, July 26, 2007 at 4:52:55 PM UTC+8, Amontec, Larry wrote:
> Amontec, Larry wrote:
> > Amontec, Larry wrote:
> >=20
> >> Amontec, Larry wrote:
> >>
> >>> ON NEXT MONDAY : 17-JUNE-2006
> >>>
> >>> Amontec will provide the =E2=80=98how-to=E2=80=99 program via a XILIN=
X VIRTEX XC4VLX25
> >>> 7.9Mbits bit stream) at 2.8 seconds using the Amontec JTAGkey !
> >>>
> >>> On next Monday, your Amontec JTAG key will be close to the speed of a=
=20
> >>> Xilinx Platform Cable USB for programming any FPGA and CPLD vendors=
=20
> >>> (Altera Xilinx Lattice Cypress ...)
> >>>
> >>> Come back next Monday on http://www.amontec.com !
> >>>
> >>> Laurent
> >>
> >>
> >>
> >> Hi all,
> >>
> >> You may download the Amontec SVF Player from
> >>   http://www.amontec.com/jtagkey.shtml
> >>
> >> Already tested for programming Altera Lattice Xilinx FPGA s CPLD s and=
=20
> >> FLASH s.
> >> It can be use for programming AVR ATMEGA processors too.
> >> But you may use it as custom JTAG Boundary Scan.
> >>
> >> Infini SCAN LENGTH !
> >> Infini number of TAP (number of Targets) integrating Header and=20
> >> Trailer scans.
> >>
> >> The amtsvfplayer.exe comes with c project source. Also, you may edit=
=20
> >> the source, customize it and re-compile a new SVF Player for your=20
> >> specific needs.
> >>
> >> amtsvfplayer.exe -h to get help on usage.
> >>
> >> You may execute SVF Files or SVF Lines.
> >> A SVF Line could be a concatenation of SVF commands.
> >>
> >> You may adapt JTAG Frequency (FREQUENCY) via -frequencyFactor. In this=
=20
> >> way you do not need to edit the SVF yourself. When using=20
> >> -frequencyFactor, the RUNTEST x TCK is automaticaly updated ...
> >>
> >> Linux version ready to be published.
> >>
> >> HAVE FUN WITH JTAG AND SVF !
> >> ... but you need to have the JTAGkey.
> >>
> >> Regards,
> >> Laurent
> >>   http://www.amontec.com
> >>
> >> Ann: via JTAGkey, you have a lot of ARM Debug Solutions too, including=
=20
> >> OpenOCD JTAG server, Crossworks, Yagarto ... !
> >=20
> >=20
> > Timing for small devices:
> >=20
> > Xilinx Coolrunner XCR3128 ERASE / PROGRAM / VERIFY ->
> > JTAG generation from SVF Player
> > SVF used :
> >  http://www.amontec.com/chm_appl_test_led_blink_prog_check.svf
> >  ... in 601 milliseconds
> >=20
> > ScreenShot :
> >  http://www.amontec.com/jtagkey.shtml
> >=20
> >  Regards,
> >  Laurent
> We have tested with an big Altera EPC2S 16.9Mbits bitstream (SVF file)=20
> and the Amontec JTAG download it after a 4.4 seconds !
> Laurent
>   http://www.amontec.com


Article: 159316
Subject: Re: C to FPGA
From: =?UTF-8?Q?Jan_Marjanovi=C4=8D?= <jancooo@gmail.com>
Date: Wed, 5 Oct 2016 00:37:40 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Sunday, October 2, 2016 at 2:40:25 AM UTC+2, Rick C. Hodgin wrote:
> At about 35 minutes or so he also talks about a startup company
> that licensed the toolset for commercial use.  The presenter
> said they have expanded the toolset into C++.  They are former
> students of his.
>=20
> Best regards,
> Rick C. Hodgin

The tool he is talking about is xPilot, which was then licensed to AutoESL =
under the name AutoPilot. The AutoESL was later bought by Xilinx which re-b=
randed the tool as Vivado HLS. The signs of it previous name still remain i=
n the names of the types, e.g. ap_int, ap_fixed.

Article: 159317
Subject: Re: C to FPGA
From: "Rick C. Hodgin" <rick.c.hodgin@gmail.com>
Date: Wed, 5 Oct 2016 01:11:05 -0700 (PDT)
Links: << >>  << T >>  << A >>
Jan Marjanovi=C4=8D wrote:
> The tool he is talking about is xPilot, which was then licensed
> to AutoESL under the name AutoPilot. The AutoESL was later
> bought by Xilinx which re-branded the tool as Vivado HLS. The
> signs of it previous name still remain in the names of the types,
> e.g. ap_int, ap_fixed.

Thank you!  Linked here:

    https://www.xilinx.com/products/design-tools/vivado/integration/esl-des=
ign.html

Best regards,
Rick C. Hodgin

Article: 159318
Subject: How do I preserve Hazard safety terms?
From: Johann Klammer <klammerj@NOSPAM.a1.net>
Date: Thu, 06 Oct 2016 03:26:39 +0200
Links: << >>  << T >>  << A >>
for muxen. during combinatorial optimization. in berkeley-abc. 
I am using the binary aig format for importing. 
It knows only about `and' and `inverter' gates. 
During optimization the safety terms get dropped 
(the AB in: Ax + B~x + AB)
Should I use a different import format? 
Which one? 
I'd like to end up with a .pla file or 
similar in the end. 

If you think this is offtopic feel free 
to suggest another ng...


Article: 159319
Subject: Re: How do I preserve Hazard safety terms?
From: KJ <kkjennings@sbcglobal.net>
Date: Wed, 5 Oct 2016 18:41:27 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Wednesday, October 5, 2016 at 9:26:45 PM UTC-4, Johann Klammer wrote:
> for muxen. during combinatorial optimization. in berkeley-abc. 
> I am using the binary aig format for importing. 
> It knows only about `and' and `inverter' gates. 
> During optimization the safety terms get dropped 
> (the AB in: Ax + B~x + AB)
> Should I use a different import format? 
> Which one? 
> I'd like to end up with a .pla file or 
> similar in the end. 
> 
> If you think this is offtopic feel free 
> to suggest another ng...

I have no idea what tool you are using, but you'll need to look into the tool specific way to preserve signals.

Kevin Jennings

Article: 159320
Subject: Re: How do I preserve Hazard safety terms?
From: Johann Klammer <klammerj@NOSPAM.a1.net>
Date: Thu, 06 Oct 2016 05:17:16 +0200
Links: << >>  << T >>  << A >>
On 10/06/2016 03:41 AM, KJ wrote:
> 
> I have no idea what tool you are using, but you'll need to look into
> the tool specific way to preserve signals.
> 
> Kevin Jennings
> 
It's not about a signal, but a (redundant) term getting lost during the
simplification (in abc here: <https://bitbucket.org/alanmi/abc>)
That is, the term is redundant w.r.t logic, but not in terms of timing(glitches). 
Searching for `hazard' in the repository (.c files) does not give a match. 
There are methods in there to find muxen, so maybe sthg can be cobbled 
together from that. 
But before doing that I'd rather ask here if I've missed something, or
maybe there's something similar wot can do this already. 


Article: 159321
Subject: Re: How do I preserve Hazard safety terms?
From: BobH <wanderingmetalhead.nospam.please@yahoo.com>
Date: Wed, 5 Oct 2016 20:55:05 -0700
Links: << >>  << T >>  << A >>
On 10/05/2016 08:17 PM, Johann Klammer wrote:
> On 10/06/2016 03:41 AM, KJ wrote:
>>
>> I have no idea what tool you are using, but you'll need to look into
>> the tool specific way to preserve signals.
>>
>> Kevin Jennings
>>
> It's not about a signal, but a (redundant) term getting lost during the
> simplification (in abc here: <https://bitbucket.org/alanmi/abc>)
> That is, the term is redundant w.r.t logic, but not in terms of timing(glitches).
> Searching for `hazard' in the repository (.c files) does not give a match.
> There are methods in there to find muxen, so maybe sthg can be cobbled
> together from that.
> But before doing that I'd rather ask here if I've missed something, or
> maybe there's something similar wot can do this already.
>

Assuming that the safety terms are getting removed at synthesis time,
look for a "SET NOTOUCH" directive. I have used it with Xilinx tools in 
similar situations with Verilog, and it worked.

BobH

Article: 159322
Subject: Re: How do I preserve Hazard safety terms?
From: Johann Klammer <klammerj@NOSPAM.a1.net>
Date: Thu, 06 Oct 2016 06:56:15 +0200
Links: << >>  << T >>  << A >>
On 10/06/2016 05:55 AM, BobH wrote:
> 
> Assuming that the safety terms are getting removed at synthesis time,
> look for a "SET NOTOUCH" directive. I have used it with Xilinx tools in similar situations with Verilog, and it worked.
> 
> BobH
You can preserve them with abc? (That's where they disappear here.) what commands do you use?
Here's what I used (on a popen()ed abc instance.. C code):

extern void
dump_pla15 (syn_ctx * ctx)
{
      FILE *fp = ctx->abcfp;
      char *buf = NULL;
      asprintf (&buf, "%s/%s", ctx->tmpdir, "atf15.pla");
      fprintf (fp, "read_aiger %s/nopt.aig\n", ctx->tmpdir);
      fprintf (fp, "drw\n");
      fprintf (fp, "refactor\n");
      fprintf (fp, "collapse\n");
      fprintf (fp, "write_pla %s\n", buf);
      fflush (fp);
      free (buf);
      buf = NULL;

}


Article: 159323
Subject: xilinx aurora lane order
From: colin <colin_toogood@yahoo.com>
Date: Thu, 6 Oct 2016 01:40:32 -0700 (PDT)
Links: << >>  << T >>  << A >>
Guys

I have two FPGAs with 4 MGTs connected between them using Aurora. The firmware guy has insisted (and I've taken a quick look myself) that we cannot define the link order. This means that I have to layout the PCB with the MGTs crossing over each other.

Really?

I can't easily ask Xilinx directly because it is the firmware guys responsibility hence my post here.
Does anyone here know whether this is definitely the case or not?

Sorry to use google to post this. I am certain that making a technical request to an admin dept run by HP in India to allow me proper usenet access will not succeed.

Colin

Article: 159324
Subject: Re: How do I preserve Hazard safety terms?
From: rickman <gnuarm@gmail.com>
Date: Thu, 6 Oct 2016 04:53:46 -0400
Links: << >>  << T >>  << A >>
On 10/5/2016 11:17 PM, Johann Klammer wrote:
> On 10/06/2016 03:41 AM, KJ wrote:
>>
>> I have no idea what tool you are using, but you'll need to look into
>> the tool specific way to preserve signals.
>>
>> Kevin Jennings
>>
> It's not about a signal, but a (redundant) term getting lost during the
> simplification (in abc here: <https://bitbucket.org/alanmi/abc>)
> That is, the term is redundant w.r.t logic, but not in terms of timing(glitches).
> Searching for `hazard' in the repository (.c files) does not give a match.
> There are methods in there to find muxen, so maybe sthg can be cobbled
> together from that.
> But before doing that I'd rather ask here if I've missed something, or
> maybe there's something similar wot can do this already.

I may be way off base here, but I think this is something that is not 
applicable to FPGAs.  FPGAs use a LUT for logic.  This is exactly 
equivalent to the Karnaugh map table that is filled in with 1s and 0s. 
Notice I didn't say anything about grouping terms for simplification. 
That is because none of that is needed when you have such a table. 
Since there is no grouping of terms, preserving term groups is meaningless.

Are you intending for the logic to generate multiple LUTs with these 
terms separate and another LUT to OR them together?

I can't say for sure about every FPGA family, but Xilinx has indicated 
they design the muxes in their LUTs to be hazard proof for the problem 
you are trying to prevent.  They do this by the use of transmission 
gates rather than logic.  As the transmission gates turn off and on, the 
capacitance of the output line keeps the present value until the next 
transmission gate turns on driving the output to the new value.  If the 
old and new values are the same, no glitch guaranteed.

Does this address your concerns?

-- 

Rick C



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
2017JanFebMarApr2017

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