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
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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 156525

Article: 156525
Subject: Re: more than 58'000 false paths...
From: al.basili@gmail.com (alb)
Date: 15 Apr 2014 07:40:07 GMT
Links: << >>  << T >>  << A >>
Hi Bob,

BobH <wanderingmetalhead.nospam.please@yahoo.com> wrote:
>> I started adding false paths to my design (see this thread for a
>> context: <boojj9FgihhU1@mid.individual.net>) but in order to avoid funny
>> names, I started to add wildcards.
[]
> 
> I think you need to do your false path declaration from clock domain to 
> clock domain, not register to register.

There's no clock domain crossing, everything is on the same clock 
domain.

I agree with what Kevin said: you need to track individual paths! I did 
this simply looking at the critical path reported by the synthesis tool 
and verifying it was a path involving my (in)famous fpu.

I spent 20h of synthesis runs to spot all the paths (essentially 30min 
each path!), now the problem is that the par is not able to fit timing 
constraints (clock frequency only). Occupancy level is not huge (60%) so 
I'm a bit puzzled.

Article: 156526
Subject: systemC and OSVVM (was: Re: [cross-post] group on systemC language)
From: al.basili@gmail.com (alb)
Date: 15 Apr 2014 07:42:35 GMT
Links: << >>  << T >>  << A >>
Hi Hans,
In comp.arch.fpga HT-Lab <hans64@htminuslab.com> wrote:
[]
>> I'm considering the possibility to have my model written in SystemC 
>> while the testbench written in vhdl, leveraging the benefits of the 
>> OSVVM library.
> 
> That is unusual, I suspect you are better off using SCV as you might hit 
> some mix language interface issues (records are not always 
> straightforward on a SC/VHDL interface, use simple structs on SC only).

There are two motivations behind this choice:

1. our system engineer is willing to dig into systemC for architecture 
exploration in the first place. We can profit of the model in order to 
build our verification environment *soon* in the project.

2. our fpga guys are not so much willing to spend time in learning 
systemC, while they could feel more confortable with the OSVVM since 
they know already the language.

The first point is a structural element that we are missing in our 
design flow. Too often the architecture is based on not so well founded 
choices and as the systems grow more complex, there's an increasing need 
to get the architecture right at the very beginning.

The second point is to enhance our current verification flow which is 
too often lagging behind. There's an unreasonable perception that going 
to the bench soon will reveal problems quicker. If we had a reference 
model and a verification environment early in the project I believe we 
can shift our mindset and spend less time in testing/debugging the 
hardware.

Article: 156527
Subject: Re: Help: Altera megafunctions, Quartus II
From: Theo Markettos <theom+news@chiark.greenend.org.uk>
Date: 15 Apr 2014 10:54:45 +0100 (BST)
Links: << >>  << T >>  << A >>
Bruce Varley <bv@nospam.com> wrote:
> I'm an FPGA newbie, working with the freeware Altera Quartus II IDE. I
> used the megafunction builder to create a FIFO memory, the .v file it
> generated is similar to the virtual prototypes created for COM interfaces,
> with a data structure and no functions.  Is this all that the megafunction
> builder provides, and I need to write my own Verilog code for eg.  bumping
> the address registers and generating handshake signals?  Or is that code
> generated for me already in a file that I haven't found yet?  TIA

Megafunctions can instantiate internal FPGA structures - so the Megafunction
.v just instantiates another module without any actual code, which looks
like a prototype.  The synthesis tool does however know about this and
'links' it with the right logic.  The Megafunction header .v is mostly about
declaring the right parameters to the internal module, and also saving the
configuration (in comments at the bottom) so you can go in and edit it with
the GUI next time.

As well as physical hardware blocks, Megafunctions can instantiate private
Altera modules or encrypted IP, so you might not be able to see the
internals.  You can also ask them to make testbenches to try out the
function in the simulator.  I'd have a look at that first to see what the
interface looks like (the manual PDF will also tell you).

Theo

Article: 156528
Subject: Re: systemC and OSVVM
From: al.basili@gmail.com (alb)
Date: 15 Apr 2014 10:59:30 GMT
Links: << >>  << T >>  << A >>
My apologies, I should have really cross-posted this subthread to 
comp.lang.vhdl as well in the first place. alb <al.basili@gmail.com> 
wrote:
> Hi Hans,
> In comp.arch.fpga HT-Lab <hans64@htminuslab.com> wrote:
> []
>>> I'm considering the possibility to have my model written in SystemC 
>>> while the testbench written in vhdl, leveraging the benefits of the 
>>> OSVVM library.
>> 
>> That is unusual, I suspect you are better off using SCV as you might hit 
>> some mix language interface issues (records are not always 
>> straightforward on a SC/VHDL interface, use simple structs on SC only).
> 
> There are two motivations behind this choice:
> 
> 1. our system engineer is willing to dig into systemC for architecture 
> exploration in the first place. We can profit of the model in order to 
> build our verification environment *soon* in the project.
> 
> 2. our fpga guys are not so much willing to spend time in learning 
> systemC, while they could feel more confortable with the OSVVM since 
> they know already the language.
> 
> The first point is a structural element that we are missing in our 
> design flow. Too often the architecture is based on not so well founded 
> choices and as the systems grow more complex, there's an increasing need 
> to get the architecture right at the very beginning.
> 
> The second point is to enhance our current verification flow which is 
> too often lagging behind. There's an unreasonable perception that going 
> to the bench soon will reveal problems quicker. If we had a reference 
> model and a verification environment early in the project I believe we 
> can shift our mindset and spend less time in testing/debugging the 
> hardware.

Article: 156529
Subject: how to specify which feature for a license
From: al.basili@gmail.com (alb)
Date: 15 Apr 2014 13:32:22 GMT
Links: << >>  << T >>  << A >>
Hi everyone,

we have a license server that hosts both ACTEL_SUMMIT feature (1 seat) 
and ACTEL_VISTA one (10 seats).

Is there a way in Designer to specify either from the command line or 
through some environment variables the feature I want for a specific 
session?

The two features are forced to be on the same file since lmgrd cannot 
handle separate files, but it looks like that when I launch the tool the 
first unassigned feature is used.

I haven't seen anything similar in the flexlm documentation and/or the 
designer command line options.

Any pointer is appreciated.

Al

-- 
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

Article: 156530
Subject: Re: more than 58'000 false paths...
From: rickman <gnuarm@gmail.com>
Date: Tue, 15 Apr 2014 12:46:02 -0400
Links: << >>  << T >>  << A >>
On 4/14/2014 9:37 PM, KJ wrote:
> On Monday, April 14, 2014 8:48:15 PM UTC-4, BobH wrote:
>>
>>
>> I think you need to do your false path declaration from clock domain to
>>
>> clock domain, not register to register.
>>
>
> Don't think so, the paths are between registers.  Saying that every transfer between clock domains is overly pessimistic (based on the OP's posting in the other thread that he referenced).
>
> Just in general, the bad thing about marking clock domain to clock domain as being a false path rather than individual (or wild carded) paths is that there no check that you don't incorrectly insert such a crossing.  If you declare all clock domain crossings to be false, you have nothing in the timing analyzer to check that you haven't overlooked something.  If you do declare them by path, then at least you would have had to look at the path at some time and convince yourself that the path is not valid.  It's not foolproof but it's better than nothing...unless of course it means that now the design won't build.

I don't follow at all.  If you have paths between unrelated clocks, they 
can't be analyzed by STA because there is no clock period to the path. 
These paths must be correct by design and require special attention 
separate from STA.

Are you saying that by adding them by path you are using STA as your 
check list to verify that you have caught all such paths?  I guess that 
has some use, but it can be a lot of work and as you say, no guarantee. 
  If it becomes cumbersome as the OP seems to be indicating, I think 
this can be omitted or perhaps used once to verify your special handling 
list and then omitted to speed up the rest of the design process.

-- 

Rick

Article: 156531
Subject: Re: more than 58'000 false paths...
From: rickman <gnuarm@gmail.com>
Date: Tue, 15 Apr 2014 12:48:29 -0400
Links: << >>  << T >>  << A >>
On 4/15/2014 3:40 AM, alb wrote:
> Hi Bob,
>
> BobH <wanderingmetalhead.nospam.please@yahoo.com> wrote:
>>> I started adding false paths to my design (see this thread for a
>>> context: <boojj9FgihhU1@mid.individual.net>) but in order to avoid funny
>>> names, I started to add wildcards.
> []
>>
>> I think you need to do your false path declaration from clock domain to
>> clock domain, not register to register.
>
> There's no clock domain crossing, everything is on the same clock
> domain.
>
> I agree with what Kevin said: you need to track individual paths! I did
> this simply looking at the critical path reported by the synthesis tool
> and verifying it was a path involving my (in)famous fpu.
>
> I spent 20h of synthesis runs to spot all the paths (essentially 30min
> each path!), now the problem is that the par is not able to fit timing
> constraints (clock frequency only). Occupancy level is not huge (60%) so
> I'm a bit puzzled.

What is your clock rate?  What part of the design is failing timing?  I 
thought you were going to set the timing of the FPU to match what the 
tools would produce...  Are you saying the non-FPU portion of the design 
is failing timing?

-- 

Rick

Article: 156532
Subject: Re: more than 58'000 false paths...
From: KJ <kkjennings@sbcglobal.net>
Date: Tue, 15 Apr 2014 12:17:22 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Tuesday, April 15, 2014 12:46:02 PM UTC-4, rickman wrote:
> > Just in general, the bad thing about marking clock domain to clock doma=
in as=20
> > being a false path rather than individual (or wild carded) paths is tha=
t=20
> > there no check that you don't incorrectly insert such a crossing.  If y=
ou=20
> > declare all clock domain crossings to be false, you have nothing in the=
=20
> > timing analyzer to check that you haven't overlooked something.  If you=
 do=20
> > declare them by path, then at least you would have had to look at the p=
ath at=20
> > some time and convince yourself that the path is not valid.  It's not=
=20
> > foolproof but it's better than nothing...unless of course it means that=
 now=20
> > the design won't build.=20

> I don't follow at all.  If you have paths between unrelated clocks, they=
=20
> can't be analyzed by STA because there is no clock period to the path.=20

You can have them analyzed.  Other than to point out where this is a crossi=
ng though I'm not sure how to really interpret the results that come out si=
nce it would depend on the relative phases and the frequencies of the clock=
s.  But I don't care about that, just the list of paths that cross.

> These paths must be correct by design and require special attention=20
> separate from STA.=20

Agreed.  But there is still value in putting something in place to verify w=
hether you are 'correct by design' or if something slipped through the crac=
ks.

> Are you saying that by adding them by path you are using STA as your=20
> check list to verify that you have caught all such paths?  I guess that=
=20
> has some use, but it can be a lot of work and as you say, no guarantee.=
=20

Yes, I use it as a check that there are no new paths created that cross dom=
ains.  It's not a lot of work since there aren't a boatload of places where=
 signals cross clock domains in the first place.  There may be no guarantee=
, but it is an additional check that gets performed on every build.  Of cou=
rse, within a clock domain and for the I/O pins, I'm using the full STA res=
ults.

> If it becomes cumbersome as the OP seems to be indicating, I think=20
> this can be omitted or perhaps used once to verify your special handling=
=20
> list and then omitted to speed up the rest of the design process

I can't say I have any idea what is going in the OP's case.  I wildcard spe=
cify paths so while I have a handful of path constraints I really don't kno=
w how many actual paths that explodes to.  I haven't had those constraints =
have any dramatic impact on P&R time like the OP is seeing.

Kevin Jennings

Article: 156533
Subject: Re: more than 58'000 false paths...
From: BobH <wanderingmetalhead.nospam.please@yahoo.com>
Date: Tue, 15 Apr 2014 17:46:22 -0700
Links: << >>  << T >>  << A >>
Hi Al,
I always considered the false path declaration to be useful for handling 
multiple clock domain issues, or getting the tool chain to ignore the 
scan clock (or scan enable) to normal clock interaction type problems. 
With a single clock domain, using the false path won't work from clock 
to clock.

If you are getting 60K expansions on 50 nets, maybe reducing the 
wildcarding would help.

Is all of your clock distribution on one of the global clock routing 
resources? Are you using clock gating?

60% utilization should not be forcing the P&R tool into choices that 
have problems. Do you have the I/O pins constrained? If so, releasing 
the pin constraints and letting the tool pick them is a useful 
troubleshooting method.

This is about all the ideas I have at this point.

Good Luck,
BobH

On 4/15/2014 12:40 AM, alb wrote:
> Hi Bob,
>
> BobH <wanderingmetalhead.nospam.please@yahoo.com> wrote:
>>> I started adding false paths to my design (see this thread for a
>>> context: <boojj9FgihhU1@mid.individual.net>) but in order to avoid funny
>>> names, I started to add wildcards.
> []
>>
>> I think you need to do your false path declaration from clock domain to
>> clock domain, not register to register.
>
> There's no clock domain crossing, everything is on the same clock
> domain.
>
> I agree with what Kevin said: you need to track individual paths! I did
> this simply looking at the critical path reported by the synthesis tool
> and verifying it was a path involving my (in)famous fpu.
>
> I spent 20h of synthesis runs to spot all the paths (essentially 30min
> each path!), now the problem is that the par is not able to fit timing
> constraints (clock frequency only). Occupancy level is not huge (60%) so
> I'm a bit puzzled.
>


Article: 156534
Subject: Nexys 4 FPGA Board
From: marwen brikcha <marwen.brikcha@gmail.com>
Date: Wed, 16 Apr 2014 18:54:55 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hi all

I'm usinf Digilent Nexys 4 FPGA BOard and I won't to run LInux kernel on microblaze and I don't have a lot of information to complete this project .

Can anyone help me (link,tutoriel, help )

THanks 
Best regards 

Article: 156535
Subject: Re: Help: Altera megafunctions, Quartus II
From: nospam@nowhere.com
Date: Thu, 17 Apr 2014 17:55:45 +0800
Links: << >>  << T >>  << A >>
On Mon, 14 Apr 2014 06:43:38 -0700 (PDT), KJ
<kkjennings@sbcglobal.net> wrote:

>On Monday, April 14, 2014 9:17:25 AM UTC-4, Bruce Varley wrote:
>> I'm an FPGA newbie, working with the freeware Altera Quartus II IDE. I used the 
>> megafunction builder to create a FIFO memory, the .v file it generated is 
>> similar to the virtual prototypes created for COM interfaces, with a data 
>> structure and no functions. Is this all that the megafunction builder provides, 
>> and I need to write my own Verilog code for eg. bumping the address registers 
>> and generating handshake signals? Or is that code generated for me already in a 
>> file that I haven't found yet? TIA
>
>Quartus has a megafunction for a FIFO, it is under 'Memory Compiler' that has a typical FIFO interface set of signals.  Which megafunction part are you using?
>
>Kevin Jennings

DCFIFO, double clocked FIFO. Using the wizard was straightforward, but
after that I'm not sure whether I need to implement the glue logic,
such as the memory address incrementing and rollaround. Sounds like I
don't (once I work out what to do to make it happen). 

Thanks for responses.

Article: 156536
Subject: Spartan 3 JTAG problems
From: Mike Perkins <spam@spam.com>
Date: Thu, 17 Apr 2014 11:50:23 +0100
Links: << >>  << T >>  << A >>
Has anyone come across an issue where an XC3S200 is recognised in 
Impact; "Right Click to Add Device or Initialize JTAG chain", and then 
can't read the device ID, status or indeed do anything else.

Power supplies on the board look good. Changed device and still the same 
problem.

Will investigate more later, but any ideas?  It can only be something 
stupid!!

-- 
Mike Perkins
Video Solutions Ltd
www.videosolutions.ltd.uk

Article: 156537
Subject: Re: Spartan 3 JTAG problems
From: =?ISO-8859-1?Q?Adam_G=F3rski?= <gorskiamalpa@wpkropkapl>
Date: Thu, 17 Apr 2014 14:37:36 +0200
Links: << >>  << T >>  << A >>
W dniu 2014-04-17 12:50, Mike Perkins pisze:
> Has anyone come across an issue where an XC3S200 is recognised in
> Impact; "Right Click to Add Device or Initialize JTAG chain", and then
> can't read the device ID, status or indeed do anything else.
>
> Power supplies on the board look good. Changed device and still the same
> problem.
>
> Will investigate more later, but any ideas?  It can only be something
> stupid!!
>

Like too long jtag cable together with too fast jtag clock speed. You 
must ensure good clock edge quality.

Best regards

Adam

Article: 156538
Subject: ERROR:HDLCompilers:27 - "ipcore_dir/Cordic_atan_synth.v" line 61
From: Raviraj Makwana <makwanaraj04@gmail.com>
Date: Fri, 18 Apr 2014 00:01:30 -0700 (PDT)
Links: << >>  << T >>  << A >>
unable to solve this error.I tried all the thing and check that there is no duplicate module..still its giving error..any one can help???plz

Article: 156539
Subject: Re: New Lattice FPGAs on 40nm ?
From: ajpkane@gmail.com
Date: Fri, 18 Apr 2014 01:38:50 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Saturday, 1 March 2014 13:34:01 UTC+1, Brane2  wrote:
> I'm playing with Lattice's MachXO2 and ECP3 for a few months now and now that MachXO3 is about to come out I wonder what happened to ECP4.
> 
> 
> 
> As I understand it, Lattice found its market niche in low-power/low-cost branch, especially now when they bought BlueSilicon and incprporated their program in ice40 series.
> 
> 
> 
> Knowing that they try to keep the cost down by using one process for all of their models and that MachXO2/ECP3 were done on 65 nm, while new ice40 and MachXO3 are on 40nm node, one would expect to see their high-end ECP4 on 40nm, too.
> 
> 
> 
> If main selling point of ECP3 was as cheapest FPGA with fast transceivers, this is diminishing now as MachXO3 will get those, too ( beside other upgrades).
> 
> 
> 
> But there is nothing on ECP4. Googling around shows 2 year old failed launch ( they obviously changed their mind) and nothing more.
> 
> 
> 
> Will there be ECP4 on 40nm and if so, what will be the update - faster transceivers or perhaps some cool ( preferably MIPS) core hardmacro onboard?
> 
> 
> 
> Or is Xilinx pushing too hard on that part of the market with Spartan-6 ?
> 
> 
> 
> I know there isn't anything official on the matter, I'm looking for more or less substantiated rumours...

Well in breaking news: ECP5 has been announced (on a 40 nm process)!

Article: 156540
Subject: Re: New Lattice FPGAs on 40nm ?
From: Brane2 <brankob@avtomatika.com>
Date: Fri, 18 Apr 2014 03:44:37 -0700 (PDT)
Links: << >>  << T >>  << A >>
Dne petek, 18. april 2014 08:38:50 UTC je oseba ajp...@gmail.com napisala:

> 
> 
> Well in breaking news: ECP5 has been announced (on a 40 nm process)!

ECP5 announcement is out probably for a few weeks now.

It feels as trimmed down as new MahXO3L is against old MachXO2.

When I complained about this, Lattice basically hinted everyone tho chill out.

MachXO3L is tweaked and parred for their biggest customers, probably for some tablets, phones etc etc.

MachXO3H is yet to come. 

And it seems like it's that way with ECP5. It's basically just redone for 40nm.

And I keep hearing those rumours about "Sapphire", so that might be it- something like ECP5-H(igh end)







Article: 156541
Subject: Re: New Lattice FPGAs on 40nm ?
From: Brane2 <brankob@avtomatika.com>
Date: Fri, 18 Apr 2014 03:50:16 -0700 (PDT)
Links: << >>  << T >>  << A >>
For those interested in MachXO:

MachX03L seems almost the same as MachXO2. At least I couldn't find any difference. And as I checked it against MachXO2 pricewise on Digikey, they came out the same.

Until someoneone pointed to "thingie" with FLASH.

MachXO3L doesn't have the same FLASH block as MachXO2 does. XO2 is reprogrammable 10.000x with data retention of 10yr. XO3L is reprogrammable _TWICE_

Or as Lattice calls it "Multi time reprogramable". With multi = 2.

But as said, this is just XO3L - XO3 part for extreme cheapscates ;o)







Article: 156542
Subject: Re: ERROR:HDLCompilers:27 -
From: "jt_eaton" <84408@embeddedrelated>
Date: Fri, 18 Apr 2014 09:06:57 -0500
Links: << >>  << T >>  << A >>
>unable to solve this error.I tried all the thing and check that there is
no duplicate module..still its giving error..any one can help???plz
>

I'm sure we could if we had access to the hdl source code.	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 156543
Subject: Re: Spartan 3 JTAG problems
From: Mike Perkins <spam@spam.com>
Date: Fri, 18 Apr 2014 18:04:25 +0100
Links: << >>  << T >>  << A >>
On 17/04/2014 11:50, Mike Perkins wrote:
> Has anyone come across an issue where an XC3S200 is recognised in
> Impact; "Right Click to Add Device or Initialize JTAG chain", and then
> can't read the device ID, status or indeed do anything else.
>
> Power supplies on the board look good. Changed device and still the same
> problem.
>
> Will investigate more later, but any ideas?  It can only be something
> stupid!!

Yes - very stupid. It seems you can initialise a chain without TDI 
connected.

Connected TDI and all's well.


-- 
Mike Perkins
Video Solutions Ltd
www.videosolutions.ltd.uk

Article: 156544
Subject: Cheap spec an using an RTL-SDR
From: Les Cargill <lcargill99@comcast.com>
Date: Fri, 18 Apr 2014 13:35:45 -0500
Links: << >>  << T >>  << A >>
http://hansvi.be/wordpress/?p=91

-- 
Les Cargill

Article: 156545
Subject: Recovering verilog source file from build files.. possible?
From: nospam@nowhere.com
Date: Mon, 21 Apr 2014 16:52:19 +0800
Links: << >>  << T >>  << A >>
My .v Verilog source files were in a separate folder to the IDE build
directory, containing all the stuff generated in the build. Then I had
a hard disk crash, and (long story) everything *except* the .v source
has been recoverable, for one, relatively small project. Is there any
way that I can back build the source from the various files that the
IDE (Altera Quartus II) creates? Even a partial reconstruction would
help, ie. I'm prepared to do some manual fossicking. There isn't any
ascii listing that I can find, everything is either binary, or tabular
stuff such as pin data. 

Article: 156546
Subject: JTAG issues Cyclone V SoC
From: Al Clark <aclark@danvillesignal.com>
Date: Mon, 21 Apr 2014 19:03:57 GMT
Links: << >>  << T >>  << A >>
I am designing my own Altera Cyclone V SoM board. It is not 
intended to be a dev board. It will be a function module that 
also includes Analog Devices' SHARC DSPs. 

I am working on the JTAG connection strategy. It seems to me 
that separate JTAG connections make more sense than chaining 
since Quartus may be running separately from the ARM (HPS).

Unless someone tells me something different, my plan is to use a 
pair of 2mm 2x5 headers, one for the FPGA and the other for the 
HPS. These would be identical to the Altera pinouts, just 
smaller. 

I expect that the board will be running uLinux, probably GCC.

Here are my questions:

1. I know that many of the Altera Cyclone V dev boards use a USB 
Blaster 2 circuit. Does anyone sell a USB Blaster 2 download 
cable? I have lots of USB Blaster clones already.

2. What should I do about the HPS TRST#. It is not supported on 
the USB Blaster?

3. The HPS Trace connections might be useful but these are 
needed for their alternate I/O functions. I am assuming that the 
Mictor interface will not be that helpful. 

I would appreciate any other comments or insight. 

Al




---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com


Article: 156547
Subject: Re: more than 58'000 false paths...
From: al.basili@gmail.com (alb)
Date: 22 Apr 2014 07:01:25 GMT
Links: << >>  << T >>  << A >>
Hi Kevin,
KJ <kkjennings@sbcglobal.net> wrote:
[]
> I can't say I have any idea what is going in the OP's case.  I 
> wildcard specify paths so while I have a handful of path constraints I 
> really don't know how many actual paths that explodes to.  I haven't 
> had those constraints have any dramatic impact on P&R time like the OP 
> is seeing.

At least Synplify Pro generates an 'sdc' file with the expanded signals 
out of your wildcards. It seems to me the file is automagically 
generated so no need to specify anything special in your settings.

A simple:

grep set_false_path file.sdc | wc -l

will do the trick (on a *nix system).

Article: 156548
Subject: Re: more than 58'000 false paths...
From: al.basili@gmail.com (alb)
Date: 22 Apr 2014 07:06:34 GMT
Links: << >>  << T >>  << A >>
Hi Rick,
rickman <gnuarm@gmail.com> wrote:
>> I spent 20h of synthesis runs to spot all the paths (essentially 30min
>> each path!), now the problem is that the par is not able to fit timing
>> constraints (clock frequency only). Occupancy level is not huge (60%) so
>> I'm a bit puzzled.
> 
> What is your clock rate?  What part of the design is failing timing?  I 
> thought you were going to set the timing of the FPU to match what the 
> tools would produce...  Are you saying the non-FPU portion of the design 
> is failing timing?

After my last 56hours run and some easter eggs (no pun intended) in 
between, I've realized there are additional paths of my FPU which were 
ok during synthesis but failed after p&r. I guess now I need to add 
additional false paths after they have been flagged as failing after 
p&r...

I have to say that this is an endless story and I'm not sure where it is 
going to get me. After all those hours I guess now it would have been 
more reliable and less painful to pipeline the design (sigh!).

Al

Article: 156549
Subject: Re: more than 58'000 false paths...
From: al.basili@gmail.com (alb)
Date: 22 Apr 2014 07:13:01 GMT
Links: << >>  << T >>  << A >>
Hi Bob,
BobH <wanderingmetalhead.nospam.please@yahoo.com> wrote:
[]
> I always considered the false path declaration to be useful for handling 
> multiple clock domain issues, or getting the tool chain to ignore the 
> scan clock (or scan enable) to normal clock interaction type problems. 

Please refer to my other thread on 'path verification' to follow the 
insanity of what I've been asked to do.

> With a single clock domain, using the false path won't work from clock 
> to clock.

false paths are from clock to D.

> If you are getting 60K expansions on 50 nets, maybe reducing the 
> wildcarding would help.

Uhm, I do not think I have much of a choice if I do not want to change 
the constraint file over and over again.

> 
> Is all of your clock distribution on one of the global clock routing 
> resources? Are you using clock gating?

I haven't done any check about the clock beeing used on a single clock 
routing resource, but I guess is not since typically those chips are 
devided in quadrants and each quadrant has its own clock resource.

I'm not sure if I need to pay extra attention to quadrant crossing clocks...

> 
> 60% utilization should not be forcing the P&R tool into choices that 
> have problems. Do you have the I/O pins constrained? If so, releasing 
> the pin constraints and letting the tool pick them is a useful 
> troubleshooting method.

There are no I/O pins at all, the design is meant to be used as a block 
since we cannot afford to re-do the exercise everytime we integrate the 
module within another project.

> This is about all the ideas I have at this point.

Thanks for sharing them.

Al



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
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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