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 158625

Article: 158625
Subject: Re: Source control and ip cores
From: Ilya Kalistru <stebanoid@gmail.com>
Date: Sun, 7 Feb 2016 05:50:25 -0800 (PST)
Links: << >>  << T >>  << A >>
On Sunday, February 7, 2016 at 3:15:25 PM UTC+3, Brian Drummond wrote:
> On Sun, 07 Feb 2016 00:11:17 -0800, Ilya Kalistru wrote:
> 
> > I'm looking for a peace of advice.
> > Currently I use git for version control in my VHDL projects and I
> > usually include all .vhd files as well as .xdc constrains files in it.
> > But I don't know what I should do with ip cores. Including the whole
> > directory of ip core to repository doesn't seem to be a good idea
> > because there are to many files and too many of them are changed after
> > any change of ip settings. Other choice, manual description of ip
> > settings in comments is tedious and error prone.
> 
> I hear you loud and clear. FPGA tool vendors are a couple of decades 
> behind in their understanding of development practices, and often don't 
> seem to consider version control at all.
> 
> It takes some digging and experimentation to work out which  
> configuration files you need to regenerate the IP cores from, and how to 
> regenerate them with minimal GUI interaction.
> 
> Maybe worth digging around in the "command log" files to see which 
> command line tools are run when you press "Generate", and which files 
> they take as inputs. That command line can then be extracted for 
> scripting the process.
> 
> Specific details will depend on the tools of course.
> 
> -- Brian

Ok. That is the approach I'm going to try. It has one disadvantage - configuration files are not really human-readable (xilinx .xci), but it looks like the best way by now.
Thank you for response.

Article: 158626
Subject: Re: Source control and ip cores
From: gtwrek@sonic.net (Mark Curry)
Date: Mon, 8 Feb 2016 17:36:42 -0000 (UTC)
Links: << >>  << T >>  << A >>
In article <n97cbb$re0$2@dont-email.me>,
Brian Drummond  <brian@shapes.demon.co.uk> wrote:
>On Sun, 07 Feb 2016 00:11:17 -0800, Ilya Kalistru wrote:
>
>> I'm looking for a peace of advice.
>> Currently I use git for version control in my VHDL projects and I
>> usually include all .vhd files as well as .xdc constrains files in it.
>> But I don't know what I should do with ip cores. Including the whole
>> directory of ip core to repository doesn't seem to be a good idea
>> because there are to many files and too many of them are changed after
>> any change of ip settings. Other choice, manual description of ip
>> settings in comments is tedious and error prone.
>
>I hear you loud and clear. FPGA tool vendors are a couple of decades 
>behind in their understanding of development practices, and often don't 
>seem to consider version control at all.

Preach it Brian.  Version control (at least for vendor X) is a late
addition, very poorly bolted on.  The design flows were created with 
an image of a single user owning and maintaining a single FPGA by
themselves.  Very 90's.

>
>It takes some digging and experimentation to work out which  
>configuration files you need to regenerate the IP cores from, and how to 
>regenerate them with minimal GUI interaction.
>

This.  We'll often check in a zip'ed archive of the dummy run we used to create
the IP - along with ALL it's junk.  Just for information purposes.  
As to what's actually USED in FPGA development, we usually peel back all the 
layers of cruft, and find the source RTL under all the chaff.  That's
what's actually used in our scripts / development.   

It's usually much more flexible to use the actual RTL as well, as opposed to 
the crap they bolt on top of it.

Regards,

Mark


Article: 158627
Subject: Re: Fully preposterous gate arranger
From: Kevin Neilson <kevin.neilson@xilinx.com>
Date: Mon, 8 Feb 2016 15:12:06 -0800 (PST)
Links: << >>  << T >>  << A >>
>  ... If you 
> wanted to push the clock frequency, and especially if you were going to 
> run multiple boards, then arranging things for best propagation delay 
> would get -- interesting.
> 

This reminds me of the odd shape of the Cray 1.  Effective, but probably a pain to assemble and debug.  I think the bus wires of the Cray were also cut to the same length to reduce skew.

Article: 158628
Subject: Re: Source control and ip cores
From: Theo Markettos <theom+news@chiark.greenend.org.uk>
Date: 09 Feb 2016 00:19:52 +0000 (GMT)
Links: << >>  << T >>  << A >>
Mark Curry <gtwrek@sonic.net> wrote:
> In article <n97cbb$re0$2@dont-email.me>,
> Brian Drummond  <brian@shapes.demon.co.uk> wrote:
> >
> >I hear you loud and clear. FPGA tool vendors are a couple of decades 
> >behind in their understanding of development practices, and often don't 
> >seem to consider version control at all.

I'm also quite tired of vendors trying to re-implement their own version
control systems.  Altium has 'vaults', for instance, which are essentially a
poor interface to Subversion ten years too late.  The files are still binary
and there's no usable merging.  That's no good when your vcs of choice is
git/bzr/hg/...

> This.  We'll often check in a zip'ed archive of the dummy run we used to
> create the IP - along with ALL it's junk.  Just for information purposes. 
> As to what's actually USED in FPGA development, we usually peel back all
> the layers of cruft, and find the source RTL under all the chaff.  That's
> what's actually used in our scripts / development.
> 
> It's usually much more flexible to use the actual RTL as well, as opposed
> to the crap they bolt on top of it.

We have the opposite problem.  As an open source project we cannot ship the
vendor RTL, because it usually says (c) Vendor, Do Not Distribute or
something on it.  But checking in the vendor RTL is the only way to get
things done.

So we have a split workflow: devs check in whatever vendor cruft into the
private repo they need to make things work.  Then, when we want to cut a
public release, we have to go through and work out how to generate the RTL
from licence-clean sources by some invocation of the tools.  Once the
invocations are put in the makefile, we can then build and check things
still work with the generated RTL.  Unfortunately the tools are often not
friendly to this workflow.

Theo

Article: 158629
Subject: Re: watermarking on FPGA
From: Tom Gardner <spamjunk@blueyonder.co.uk>
Date: Wed, 10 Feb 2016 09:05:45 +0000
Links: << >>  << T >>  << A >>
On 03/02/16 13:36, Hamid Kavianathar wrote:
> I'm going to do a very simple watermarking. I want to embed a signature on unused LUTs. could you please tell me how I can do it?
> Thank you very much.

What *problem* are you trying to solve with "watermarking"?
Only after defining that can you begin to think whether
watermarking is a sufficient solution.

"If you think cryptography will solve your problem,
you don't understand cryptography and
you don't understand your problem".


Article: 158630
Subject: EPM240T100C5N, LM2596, USB Blaster.
From: emailbogsuv@gmail.com
Date: Wed, 10 Feb 2016 10:15:12 -0800 (PST)
Links: << >>  << T >>  << A >>
How to make it visible in QuartusII ?

Pinout cpld ?

How to solder it to pcb ?

Links ?

Article: 158631
Subject: Re: EPM240T100C5N, LM2596, USB Blaster.
From: Emilian Miron <emilian.miron@gmail.com>
Date: Thu, 11 Feb 2016 11:58:18 -0800 (PST)
Links: << >>  << T >>  << A >>
You can find some minimal development boards on ebay / aliexpress. I've used these successfully.

Some include a USB Blaster device as well. Something like this:
http://www.ebay.com/itm/Altera-MAX-II-EPM240-Core-Board-FPGA-CPLD-Development-Kits-JTAG-USB-Blaster-/330813186044?hash=item4d06009ffc:g:mZ0AAOSwDk5TwKe3

If you look for Altera's documentation about JTAG and Max II devices you'll find the pinout for the MAX 2 device.

If you install Quartus II and attach the JTAG to the board you should see the device in the programmer without much hassle.

Altera has a lot of video classes on their website that you can use to learn the workflow - I definitely recommend them.

The package I tried soldering was a TQFP100 (0.5mm pitch). Personally I had limited success on the first try on a PCB breakout board:
- misaligned the TQFP pins so I had to hot air it off the board and realign.
- lots of shorts while soldering everything
- using solder wick I removed most shorts but bent the pins so there are a few shorts.

I'm going to try soldering another one again. Hopefully I'll be more successful this time.

If you're ordering your own PCBs, having some larger uncovered traces help suck the additional solder away from pins to remove shorts. On my breakout the pads were pretty small and the rest of the traces going away from the pad were covered by soldermask.

Good luck!
Emilian

On Wednesday, February 10, 2016 at 1:15:19 PM UTC-5, email...@gmail.com wrote:
> How to make it visible in QuartusII ?
> 
> Pinout cpld ?
> 
> How to solder it to pcb ?
> 
> Links ?

Article: 158632
Subject: Re: EPM240T100C5N, LM2596, USB Blaster.
From: Jon Elson <jmelson@wustl.edu>
Date: Thu, 11 Feb 2016 15:48:27 -0600
Links: << >>  << T >>  << A >>
Emilian Miron wrote:

 
> The package I tried soldering was a TQFP100 (0.5mm pitch). Personally I
> had limited success on the first try on a PCB breakout board: - misaligned
> the TQFP pins so I had to hot air it off the board and realign. - lots of
> shorts while soldering everything - using solder wick I removed most
> shorts but bent the pins so there are a few shorts.
You need very fine solder, .010" if you can get it, or .015" if you can't 
get the thinner stuff.  A soldering iron with an insanely small, sharp 
point.  My technique is to put a dab of solder on two diagonal pads.  Attach 
the chip to those pads, and then check the alignment.  You can "walk" the 
chip a bit to get good alignment on all 4 sides, by heating one of those 
pads, then the other.  When alignment is good, apply liquid flux to all four 
rows of leads.  Apply it liberally, so the whole area where the leads touch 
the pads are covered with flux.  Then, apply the soldering iron to one pin 
at a time, working your way around the chip.  If the PC board has heavy 
solder plate, you won't need to add any solder.  If the plate is thin, you 
may need to add solder every 3rd or 4th lead.  You will need micro-size 
sloder wick for the inevitable bridges.  I dip the solder wick in the same 
liquid flux I use in this process.  It is messier, but works WAY better when 
it has lots of flux on it.

I've soldered hundreds of TQFP chips in the 100, 128 and 144 size.  The 
smallest were 128-lead with 0.4mm pitch.

Jon

Article: 158633
Subject: Synplify Identify with Microsemi FPGAs
From: "ees3dc" <93907@FPGARelated>
Date: Mon, 15 Feb 2016 04:45:39 -0600
Links: << >>  << T >>  << A >>
Is anybody out there using Microsemi's Libero SoC and the bundled Synplfiy
Identify?

Identify is giving me problems:

1. It will not accept a depth of  greater than 128 even when I ask for it
2. Gives completely wrong and impossible waveform results and gives the
error message:
ERROR: objectsdb_type.cpp:207: assertion '0' failed

Since Synplify is bundled by Microsemi, I have no support with Synosys,
nor is there an Actel/Microsemi forum to ask on.

thanks
---------------------------------------
Posted through http://www.FPGARelated.com

Article: 158634
Subject: Re: Synplify Identify with Microsemi FPGAs
From: Kevin Neilson <kevin.neilson@xilinx.com>
Date: Wed, 17 Feb 2016 15:08:53 -0800 (PST)
Links: << >>  << T >>  << A >>
I don't have an answer, but I sympathize.  I did a couple of RTAX designs, =
and the tools are pretty primitive.  Synplify for the Actel does not work a=
s well as it does for other parts.  I get the idea there's one guy at Synop=
sis who spends one day a week on Actel support.

Article: 158635
Subject: Where is a code example on how to use a floating multiplier on FPGA
From: Weng Tianxiang <wtxwtx@gmail.com>
Date: Sun, 21 Feb 2016 11:47:34 -0800 (PST)
Links: << >>  << T >>  << A >>
Hi, 

I need a full code example on how to use a floating multiplier on FPGA for VHDL-2008. What is the document name from XILINX? 

Jim's slides on floating multiplier are good, but not full and outdated. It was published on 2007. 

http://www.synthworks.com/papers/vhdl_fixedfloat_lewis_bishop_date_2007.pdf 

Thank you. 


Weng 

Article: 158636
Subject: Re: Where is a code example on how to use a floating multiplier on
From: =?UTF-8?Q?Jan_Marjanovi=C4=8D?= <jancooo@gmail.com>
Date: Sun, 21 Feb 2016 13:57:57 -0800 (PST)
Links: << >>  << T >>  << A >>
On Sunday, February 21, 2016 at 8:47:38 PM UTC+1, Weng Tianxiang wrote:
> Hi,=20
>=20
> I need a full code example on how to use a floating multiplier on FPGA fo=
r VHDL-2008. What is the document name from XILINX?=20
>=20
> Jim's slides on floating multiplier are good, but not full and outdated. =
It was published on 2007.=20
>=20
> http://www.synthworks.com/papers/vhdl_fixedfloat_lewis_bishop_date_2007.p=
df=20
>=20
> Thank you.=20
>=20
>=20
> Weng

I am not an expert for VHDL, but I would be really surprised if the tools w=
ill be able to synthesize this data type. This VHDL package is meant to be =
used for simulation.

Xilinx has an IP which does various operations on floating point: http://ww=
w.xilinx.com/products/intellectual-property/floating_pt.html. I would also =
suggest checking out Vivado HLS since (at least IMHO) gives nice productivi=
ty boost when writing floating-point signal processing modules.

Article: 158637
Subject: Re: Where is a code example on how to use a floating multiplier on
From: Weng Tianxiang <wtxwtx@gmail.com>
Date: Sun, 21 Feb 2016 16:14:20 -0800 (PST)
Links: << >>  << T >>  << A >>
On Sunday, February 21, 2016 at 1:58:03 PM UTC-8, Jan Marjanovi=C4=8D wrote=
:
> On Sunday, February 21, 2016 at 8:47:38 PM UTC+1, Weng Tianxiang wrote:
> > Hi,=20
> >=20
> > I need a full code example on how to use a floating multiplier on FPGA =
for VHDL-2008. What is the document name from XILINX?=20
> >=20
> > Jim's slides on floating multiplier are good, but not full and outdated=
. It was published on 2007.=20
> >=20
> > http://www.synthworks.com/papers/vhdl_fixedfloat_lewis_bishop_date_2007=
.pdf=20
> >=20
> > Thank you.=20
> >=20
> >=20
> > Weng
>=20
> I am not an expert for VHDL, but I would be really surprised if the tools=
 will be able to synthesize this data type. This VHDL package is meant to b=
e used for simulation.
>=20
> Xilinx has an IP which does various operations on floating point: http://=
www.xilinx.com/products/intellectual-property/floating_pt.html. I would als=
o suggest checking out Vivado HLS since (at least IMHO) gives nice producti=
vity boost when writing floating-point signal processing modules.

Hi Jan,

very good, what you provided is what I want. But can you give more info abo=
ut Vivado HLS? A pdf document link for Vivado HLS?

Thank you.=20

Weng

Article: 158638
Subject: Re: lwIP RAW mode support for V4 temac
From: vandanr007@gmail.com
Date: Mon, 22 Feb 2016 19:11:05 -0800 (PST)
Links: << >>  << T >>  << A >>
Hi, I'm trying to transfer a small .bin file of size utmost 1-2MB from PC to sdr ddrram of ML403 using a crossover Ethernet cable (TCP/IP). I'm using PowerPC and plb bus. How do I write a socket program to transfer the file?

Article: 158639
Subject: Re: Where is a code example on how to use a floating multiplier on
From: rickman <gnuarm@gmail.com>
Date: Tue, 23 Feb 2016 01:39:10 -0500
Links: << >>  << T >>  << A >>
On 2/21/2016 4:57 PM, Jan Marjanovič wrote:
> On Sunday, February 21, 2016 at 8:47:38 PM UTC+1, Weng Tianxiang
> wrote:
>> Hi,
>>
>> I need a full code example on how to use a floating multiplier on
>> FPGA for VHDL-2008. What is the document name from XILINX?
>>
>> Jim's slides on floating multiplier are good, but not full and
>> outdated. It was published on 2007.
>>
>> http://www.synthworks.com/papers/vhdl_fixedfloat_lewis_bishop_date_2007.pdf
>>
>>
>>
Thank you.
>>
>>
>> Weng
>
> I am not an expert for VHDL, but I would be really surprised if the
> tools will be able to synthesize this data type. This VHDL package is
> meant to be used for simulation.

That is not a true statement.  Floating point can be used for synthesis 
if supported by the vendor.  I have not needed floating point in a VHDL 
design so I don't know how widely it is supported, but I know there is 
nothing special about floating point that makes it unsupportable.

-- 

Rick

Article: 158640
Subject: Re: Where is a code example on how to use a floating multiplier on
From: rickman <gnuarm@gmail.com>
Date: Tue, 23 Feb 2016 01:40:10 -0500
Links: << >>  << T >>  << A >>
On 2/21/2016 7:14 PM, Weng Tianxiang wrote:
> On Sunday, February 21, 2016 at 1:58:03 PM UTC-8, Jan Marjanovič wrote:
>> On Sunday, February 21, 2016 at 8:47:38 PM UTC+1, Weng Tianxiang wrote:
>>> Hi,
>>>
>>> I need a full code example on how to use a floating multiplier on FPGA for VHDL-2008. What is the document name from XILINX?
>>>
>>> Jim's slides on floating multiplier are good, but not full and outdated.. It was published on 2007.
>>>
>>> http://www.synthworks.com/papers/vhdl_fixedfloat_lewis_bishop_date_2007..pdf
>>>
>>> Thank you.
>>>
>>>
>>> Weng
>>
>> I am not an expert for VHDL, but I would be really surprised if the tools will be able to synthesize this data type. This VHDL package is meant to be used for simulation.
>>
>> Xilinx has an IP which does various operations on floating point: http://www.xilinx.com/products/intellectual-property/floating_pt.html. I would also suggest checking out Vivado HLS since (at least IMHO) gives nice productivity boost when writing floating-point signal processing modules.
>
> Hi Jan,
>
> very good, what you provided is what I want. But can you give more info about Vivado HLS? A pdf document link for Vivado HLS?

You should be contacting the synthesis and FPGA vendors.

-- 

Rick

Article: 158641
Subject: Re: Where is a code example on how to use a floating multiplier on
From: Daniel Kho <daniel.kho@gmail.com>
Date: Tue, 23 Feb 2016 04:16:46 -0800 (PST)
Links: << >>  << T >>  << A >>
On Tuesday, 23 February 2016 14:40:15 UTC+8, rickman  wrote:
> On 2/21/2016 7:14 PM, Weng Tianxiang wrote:
> > On Sunday, February 21, 2016 at 1:58:03 PM UTC-8, Jan Marjanovi=C4=8D w=
rote:
> >> On Sunday, February 21, 2016 at 8:47:38 PM UTC+1, Weng Tianxiang wrote=
:
> >>> Hi,
> >>>
> >>> I need a full code example on how to use a floating multiplier on FPG=
A for VHDL-2008. What is the document name from XILINX?
> >>>
> >>> Jim's slides on floating multiplier are good, but not full and outdat=
ed.. It was published on 2007.
> >>>
> >>> http://www.synthworks.com/papers/vhdl_fixedfloat_lewis_bishop_date_20=
07..pdf
> >>>
> >>> Thank you.
> >>>
> >>>
> >>> Weng
> >>
> >> I am not an expert for VHDL, but I would be really surprised if the to=
ols will be able to synthesize this data type. This VHDL package is meant t=
o be used for simulation.
> >>
> >> Xilinx has an IP which does various operations on floating point: http=
://www.xilinx.com/products/intellectual-property/floating_pt.html. I would =
also suggest checking out Vivado HLS since (at least IMHO) gives nice produ=
ctivity boost when writing floating-point signal processing modules.
> >
> > Hi Jan,
> >
> > very good, what you provided is what I want. But can you give more info=
 about Vivado HLS? A pdf document link for Vivado HLS?
>=20
> You should be contacting the synthesis and FPGA vendors.
>=20
> --=20
>=20
> Rick

Xilinx Vivado synthesis supports VHDL-2008, by enabling a Tcl command:
set_param project.enableVHDL2008 1

After entering this command, the Project Settings dialogue box will show a =
checkbox "Use VHDL 2008". Check this to VHDL-2008 support.

Then you can set individual files to use the "VHDL 2008" file type.

However, be warned that there is currently a problem with getting the IEEE =
floating point package (float_pkg) to work with this option enabled. Howeve=
r, previous versions of Vivado, I mean those that have not yet supported VH=
DL-2008, do actually support the float_pkg library (weird I know).

I have filed a case with Xilinx previously, but I'm not sure of its current=
 status. I believe they are working on this.

If you want to use float_pkg, you need to NOT use the "VHDL 2008" option fo=
r now. With this, you can use the "*" multiplication symbol to do floating-=
point multiplications.

Refer to Chapter 5 (pgs. 177 onwards) of the Vivado Design Suite User Guide=
 (v2015.3).
http://www.xilinx.com/support/documentation/sw_manuals/xilinx2015_3/ug901-v=
ivado-synthesis.pdf

-daniel

Article: 158642
Subject: Re: Source control and ip cores
From: Daniel Kho <daniel.kho@gmail.com>
Date: Tue, 23 Feb 2016 04:38:14 -0800 (PST)
Links: << >>  << T >>  << A >>
On Sunday, 7 February 2016 21:50:30 UTC+8, Ilya Kalistru  wrote:
> On Sunday, February 7, 2016 at 3:15:25 PM UTC+3, Brian Drummond wrote:
> > On Sun, 07 Feb 2016 00:11:17 -0800, Ilya Kalistru wrote:
> >=20
> > > I'm looking for a peace of advice.
> > > Currently I use git for version control in my VHDL projects and I
> > > usually include all .vhd files as well as .xdc constrains files in it=
.
> > > But I don't know what I should do with ip cores. Including the whole
> > > directory of ip core to repository doesn't seem to be a good idea
> > > because there are to many files and too many of them are changed afte=
r
> > > any change of ip settings. Other choice, manual description of ip
> > > settings in comments is tedious and error prone.
> >=20
> > I hear you loud and clear. FPGA tool vendors are a couple of decades=20
> > behind in their understanding of development practices, and often don't=
=20
> > seem to consider version control at all.
> >=20
> > It takes some digging and experimentation to work out which =20
> > configuration files you need to regenerate the IP cores from, and how t=
o=20
> > regenerate them with minimal GUI interaction.
> >=20
> > Maybe worth digging around in the "command log" files to see which=20
> > command line tools are run when you press "Generate", and which files=
=20
> > they take as inputs. That command line can then be extracted for=20
> > scripting the process.
> >=20
> > Specific details will depend on the tools of course.
> >=20
> > -- Brian
>=20
> Ok. That is the approach I'm going to try. It has one disadvantage - conf=
iguration files are not really human-readable (xilinx .xci), but it looks l=
ike the best way by now.
> Thank you for response.

Xilinx's configuration files aren't really that human-unreadable. I am actu=
ally amazed at how much standards support Xilinx puts into their tool and f=
lows. If you take a good look into an *.xci file with a text editor, you wi=
ll notice that it is in a human-readable XML format. And this is no ordinar=
y XML - the format of the XML actually adheres to the IP-XACT specification=
, which is indeed a portable method to package and transfer components betw=
een tools that support this specification.
https://en.wikipedia.org/wiki/IP-XACT

-daniel

Article: 158643
Subject: Re: Source control and ip cores
From: Daniel Kho <daniel.kho@gmail.com>
Date: Tue, 23 Feb 2016 04:39:42 -0800 (PST)
Links: << >>  << T >>  << A >>
On Tuesday, 23 February 2016 20:38:17 UTC+8, Daniel Kho  wrote:
> On Sunday, 7 February 2016 21:50:30 UTC+8, Ilya Kalistru  wrote:
> > On Sunday, February 7, 2016 at 3:15:25 PM UTC+3, Brian Drummond wrote:
> > > On Sun, 07 Feb 2016 00:11:17 -0800, Ilya Kalistru wrote:
> > >=20
> > > > I'm looking for a peace of advice.
> > > > Currently I use git for version control in my VHDL projects and I
> > > > usually include all .vhd files as well as .xdc constrains files in =
it.
> > > > But I don't know what I should do with ip cores. Including the whol=
e
> > > > directory of ip core to repository doesn't seem to be a good idea
> > > > because there are to many files and too many of them are changed af=
ter
> > > > any change of ip settings. Other choice, manual description of ip
> > > > settings in comments is tedious and error prone.
> > >=20
> > > I hear you loud and clear. FPGA tool vendors are a couple of decades=
=20
> > > behind in their understanding of development practices, and often don=
't=20
> > > seem to consider version control at all.
> > >=20
> > > It takes some digging and experimentation to work out which =20
> > > configuration files you need to regenerate the IP cores from, and how=
 to=20
> > > regenerate them with minimal GUI interaction.
> > >=20
> > > Maybe worth digging around in the "command log" files to see which=20
> > > command line tools are run when you press "Generate", and which files=
=20
> > > they take as inputs. That command line can then be extracted for=20
> > > scripting the process.
> > >=20
> > > Specific details will depend on the tools of course.
> > >=20
> > > -- Brian
> >=20
> > Ok. That is the approach I'm going to try. It has one disadvantage - co=
nfiguration files are not really human-readable (xilinx .xci), but it looks=
 like the best way by now.
> > Thank you for response.
>=20
> Xilinx's configuration files aren't really that human-unreadable. I am ac=
tually amazed at how much standards support Xilinx puts into their tool and=
 flows. If you take a good look into an *.xci file with a text editor, you =
will notice that it is in a human-readable XML format. And this is no ordin=
ary XML - the format of the XML actually adheres to the IP-XACT specificati=
on, which is indeed a portable method to package and transfer components be=
tween tools that support this specification.
> https://en.wikipedia.org/wiki/IP-XACT
>=20
> -daniel

Yes, I think it is a good idea to version control IP-XACT files.

-daniel

Article: 158644
Subject: Re: Source control and ip cores
From: Svenn Are Bjerkem <svenn@invalid.ed.ntnu.no>
Date: Thu, 25 Feb 2016 08:21:07 +0000 (UTC)
Links: << >>  << T >>  << A >>
Ilya Kalistru <stebanoid@gmail.com> wrote:
> I'm looking for a peace of advice.
> Currently I use git for version control in my VHDL projects and I usually
> include all .vhd files as well as .xdc constrains files in it. But I don't
> know what I should do with ip cores. Including the whole directory of ip core
> to repository doesn't seem to be a good idea because there are to many files
> and too many of them are changed after any change of ip settings. Other
> choice, manual description of ip settings in comments is tedious and error
> prone.

I check in only the xci and xml files in the sources_1/ip structure.

When checking out a pristine tree from source control and run generate
bitstream for the first time, Vivado will go through the process of
regenerating all the products of the included IP.

This is GUI workflow.

-- 
svenn

Article: 158645
Subject: Re: Source control and ip cores
From: gtwrek@sonic.net (Mark Curry)
Date: Thu, 25 Feb 2016 19:40:49 -0000 (UTC)
Links: << >>  << T >>  << A >>
In article <4b7d68c4-7824-40d8-a114-b0c331b979a2@googlegroups.com>,
Daniel Kho  <daniel.kho@gmail.com> wrote:
>On Sunday, 7 February 2016 21:50:30 UTC+8, Ilya Kalistru  wrote:
>> On Sunday, February 7, 2016 at 3:15:25 PM UTC+3, Brian Drummond wrote:
>> > On Sun, 07 Feb 2016 00:11:17 -0800, Ilya Kalistru wrote:
>> > 
>> > > I'm looking for a peace of advice.
>> > > Currently I use git for version control in my VHDL projects and I
>> > > usually include all .vhd files as well as .xdc constrains files in it.
>> > > But I don't know what I should do with ip cores. Including the whole
>> > > directory of ip core to repository doesn't seem to be a good idea
>> > > because there are to many files and too many of them are changed after
>> > > any change of ip settings. Other choice, manual description of ip
>> > > settings in comments is tedious and error prone.
>> > 
>> > I hear you loud and clear. FPGA tool vendors are a couple of decades 
>> > behind in their understanding of development practices, and often don't 
>> > seem to consider version control at all.
>> > 
>> > It takes some digging and experimentation to work out which  
>> > configuration files you need to regenerate the IP cores from, and how to 
>> > regenerate them with minimal GUI interaction.
>> > 
>> > Maybe worth digging around in the "command log" files to see which 
>> > command line tools are run when you press "Generate", and which files 
>> > they take as inputs. That command line can then be extracted for 
>> > scripting the process.
>> > 
>> > Specific details will depend on the tools of course.
>> > 
>> > -- Brian
>> 
>> Ok. That is the approach I'm going to try. It has one disadvantage - configuration 
>> files are not really human-readable (xilinx .xci), but it looks like the best way 
>> by now.
>
>Xilinx's configuration files aren't really that human-unreadable. I am actually amazed at 
>how much standards support Xilinx puts into their tool and flows. If you take a good look
>into an *.xci file with a text editor, you will notice that it is in a human-readable XML
>format. And this is no ordinary XML - the format of the XML actually adheres to the 
>IP-XACT specification, which is indeed a portable method to package and transfer components 
>between tools that support this specification.
>https://en.wikipedia.org/wiki/IP-XACT

(Getting ranty, and not helping the OP, but this is a sore spot for us...)

Xilinx support of standards is 2 steps forwards, 1.9 steps back.  Sure they're using 
more "industry standard" files.  (SDC, TCL).  But they're still burying the landscape
in a host of unneccesary, undocumented, randomly changing list of other ancillary 
files. 

I'm really not clear as to what IP-XACT is trying to solve, and who it's audience is.
But XCI files are a very unreliable way of managing IP.  Sure it's XML - there's
tools available to manipulate them.  But Xilinx doesn't document the
data within those files in any way.  They're free to change it at any time.
Can a user reliably MERGE changes within those files from one development
tree, and another?  Will the design still build 1, 2, 5, or 10 years 
down the line using that undocumented src file?

Can you simulate an XCI file?  Can you run lint on it?  Can you modify it's contents?
What's configurable within them?  In the end, it's just something that gets in the way
of what you really need to do those tasks - the RTL (or netlist as neccesary - 
encrypted at worst case).

Regards,

Mark

Article: 158646
Subject: Sending multiple MSI interrupts via Xilinx "AXI Memory Mapped to
From: wzab01@gmail.com
Date: Thu, 25 Feb 2016 14:09:40 -0800 (PST)
Links: << >>  << T >>  << A >>
Hi,

I wanted to prepare a small IP core able to serialize multiple interrupts as MSI interrupts handled by the Xilinx AXI MM 2 PCIe bridge.

In the newest documentation  ( http://www.xilinx.com/support/documentation/ip_documentation/axi_pcie/v2_7/pg055-axi-bridge-pcie.pdf ) it is stated that:

* Additional IP is required in the Endpoint PCIe system to create the 
  prioritization scheme for the MSI vectors on the PCIe interface.
  (that's why I want to create that core)

* intx_msi_request
  Initiates a MSI write request when msi_enable = 1.
  Intx_msi_request is asserted for one clock period.
* The intx_msi_grant signal is asserted for one clock
  period when the interrupt is accepted by the PCIe core.

Does it mean, that I should set the MSI interrupt number on msi_vector_num and assert intx_msi_request for one clock period, and then (with deasserted intx_msi_request) wait until intx_msi_grant goes high for one clock?

The more natural way would be for me to keep the intx_msi_request high until intx_msi_grant goes high...
Unfortunately the documentation does not contain any example timing diagram/waveform.

What if I have multiple interrupts to send?

Can I set the new msi_vector_num in the next cycle after asserting intx_msi_request, or should I keep the old value until it is confirmed by intx_msi_grant?

If the first option is right, may I assert intx_msi_request in the same cycle in which intx_msi_grant is asserted, to immediately send the next interrupt?

I've sent this question also to the Xilinx forum
( https://forums.xilinx.com/t5/PCI-Express/AXI-MM-2-PCIe-sending-MSI-interrupts/m-p/683865 ) but have receive no answer yet. Maybe somebody here  



Thank you in advance,
With best regards,
Wojtek

Article: 158647
Subject: Re: Source control and ip cores
From: wzab01@gmail.com
Date: Thu, 25 Feb 2016 14:25:45 -0800 (PST)
Links: << >>  << T >>  << A >>
I'm working at a big project with multiple developers and we also want to b=
e able to share sources in a version controlled friendly.
The project mainly uses X... FPGAs and V... tools.

One of possible approaches was to use IP packager, however it seems that it=
 is not possible, or at least discouraged to use IP cores with port defined=
 as VHDL records (just imagine a few AXI ports as bits and bit vectors, and=
 compare it to the clean design of IPbus with record based ports - https://=
svnweb.cern.ch/trac/cactus )

The another approach I've proposed is based on extension of the old good PR=
J files.

The file may contain lines of following types:
  - type library file
    (Line defining the source file
    Possible types: vhdl, verilog, system, header. xci, xdc
    File name (path in fact) is defined relatively to the location of the
    PRJ file)

  - include file
    (Line defining the include file
File name (path in fact) is defined relatively to the location of the
PRJ file
Use of relative paths allows easy reuse of so defined
blocks. Use of simple text files makes such solution
SVN/GIT friendly


Article: 158648
Subject: Re: Source control and ip cores
From: wzab01@gmail.com
Date: Thu, 25 Feb 2016 14:34:28 -0800 (PST)
Links: << >>  << T >>  << A >>
Oooops, sorry, I've unintentionally clicked "publish" before my message was=
 ready :-(
Here it is again in a complete form.


I'm working at a big project with multiple developers and we also want to b=
e able to share sources in a version controlled friendly.
The project mainly uses X... FPGAs and V... tools.

One of possible approaches was to use IP packager, however it seems that it=
 is not possible, or at least discouraged to use IP cores with port defined=
 as VHDL records (just imagine a few AXI ports as bits and bit vectors, and=
 compare it to the clean design of IPbus with record based ports - https://=
svnweb.cern.ch/trac/cactus )
=20
The another approach I've proposed is based on extension of the old good PR=
J files.
=20
The file may contain lines of following types:
   - type library file
     (Line defining the source file
     Possible types: vhdl, verilog, system, header. xci, xdc
     File name (path in fact) is defined relatively to the location of the
     PRJ file)
=20
   - include file
     (Line defining the include file
     File name (path in fact) is defined relatively to the location
     of the PRJ file)

Use of relative paths allows easy reuse of so defined
blocks. Use of simple text files makes such solution
SVN/GIT friendly

I've prepared a simple routine, which translates PRJ file (with included
files) to the list of files, based on the "prj_add" routine
from UG946 tutorial.=20

Here it is:

# Procedure below reads the source files from PRJ files, extended with
# the "include file" statement

#Important thing - path to the source files should be given relatively
#to the location of the PRJ file.
proc read_prj { prj } {
    #initialize results to an empty list
    set res []
    if {[file exists $prj]} {
	puts "\tReading PRJ file: $prj"
	set source [open $prj r]
	set source_data [read $source]
	close $source
	#Extract the directory of the PRJ file, as all paths to the
	#source files must be given relatively to that directory
	set prj_dir [ file dirname $prj ]
	regsub -all {\"} $source_data {} source_data
	set prj_lines [split $source_data "\n" ]
	set line_count 0
	foreach line $prj_lines {
	    incr line_count
	    #Ignore empty and commented lines
	    if {[llength $line] > 0 && ![string match -nocase "#*" $line]} {
		#Detect the inlude line
		lassign $line type file
		if {[string match -nocase $type "include"]} {
                    puts "\tIncluding PRJ file: $prj_dir/$file"
		    set inc [ read_prj $prj_dir/$file ]
		    foreach l $inc {
			lappend res $l
		    }
		} else {
		    lappend res [linsert $line 0 $prj_dir]=20
		}
	    }
	}
    }
    return $res
}

Of course the above procedure is a quick&dirty solution lacking the full er=
ror detection.

Anyway it is possible to define each IP block as a tree of directories cont=
aining sources and associated extended PRJ files.

The main disadvantage is that this approach is not supported by the tool ve=
ndor, so it is unclear whether it will work with the future versions...

Maybe this idea may be somehow improved?

With best regards,
Wojtek



Article: 158649
Subject: Re: Source control and ip cores
From: wzab01@gmail.com
Date: Thu, 25 Feb 2016 14:46:23 -0800 (PST)
Links: << >>  << T >>  << A >>
Yet one thing which was missed in my previous post.
How the read_prj procedure is used in the Tcl script building the project?
Below is the appropriate part of the Tcl script:

set prj src/top.prj
set prj_lines [ read_prj $prj ]
foreach line $prj_lines {
    # Just read the type
    puts $line
    lassign $line pdir type lib file
    # Handle the source files
    if { \
	     [string match -nocase $type "xci"]  || \
	     [string match -nocase $type "header"]  || \
	     [string match -nocase $type "system"]  || \
	     [string match -nocase $type "verilog"] || \
	     [string match -nocase $type "vhdl"]} {
	    
	set nfile [file normalize "$pdir/$file"]
	add_files -norecurse -fileset $sobj $nfile
	set file_obj [get_files -of_objects $sobj $nfile]
	#Handle VHDL file
	if {[string match -nocase $type "vhdl"]} {
	    set_property "file_type" "VHDL" $file_obj
	    set_property "library" $lib $file_obj
	}
	#Handle Verilog file
	if {[string match -nocase $type "verilog"]} {
	    set_property "file_type" "Verilog" $file_obj
	    set_property "library" $lib $file_obj
	}
	#Handle SystemVerilog file
	if {[string match -nocase $type "system"]} {
	    set_property "file_type" "SystemVerilog" $file_obj
	}
	#Handle Verilog header file
	if {[string match -nocase $type "header"]} {
	    set_property "file_type" "Verilog Header" $file_obj
	}
	#Handle XCI file
	if {[string match -nocase $type "xci"]} {
	    #set_property "synth_checkpoint_mode" "Singular" $file_obj
	}
    }
    if { [string match -nocase $type "xdc"]} {
	set nfile [file normalize "$pdir/$file"]
	add_files -norecurse -fileset $cobj $nfile
	set file_obj [get_files -of_objects $cobj $nfile]
	set_property "file_type" "XDC" $file_obj
    }	
}

With best regards,
Wojtek




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