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 156400

Article: 156400
Subject: Re: lattice Diamond on Linux - programming doesn't work...
From: Brane2 <brankob@avtomatika.com>
Date: Fri, 28 Mar 2014 15:40:31 -0700 (PDT)
Links: << >>  << T >>  << A >>
Dne petek, 28. marec 2014 10:22:22 UTC je oseba Brane2 napisala:

><SNIP>
> So, if anyone has an idea, it is welcome.

Update - it works now.

Main part of the reason is that Microchip's MPLABX decided to install its own version of libusb in /usr/local/lib and dynamic loader was picking this hacked version instead system's official one.

I deleted it and now it works. At least Diamond bundle.


Standalone programmer package still criaks but that is due to missing libraries. It seems it is missing at least libpng12.so.

But this is fixable in relatively simple way. Totally same programmer utility is within Diamond, where it works.


Looking around for solution, I've found totally old Lattice's programming cable for parallel port. It's dead simple- electronics contains only 74HC367 buffer and a couple of resistors.

And it seems that it is the same thing as current parallel port ISP cable from Lattice. 

I'm about to try it with Diamond on that MachXO2 breakout board...








Article: 156401
Subject: Re: [cross-post][long] svn workflow for fpga development
From: Brian Drummond <brian3@shapes.demon.co.uk>
Date: Sat, 29 Mar 2014 13:14:46 GMT
Links: << >>  << T >>  << A >>
On Fri, 28 Mar 2014 13:24:42 +0000, alb wrote:

> Hi Mark,
> 
> In comp.arch.fpga Mark Curry <gtwrek@sonic.net> wrote:
> []
>>>In the past I've always followed two simple rules:
>>> 1. never break the trunk 2. commit often
>> 
>> I'll add my 2 cents.  Rule 1 is not as important in my experience.
>> Having a regular regression (nightly, weekly, whatever), that runs on a
>> clean checkout of the trunk is more important.  Then you can easily
>> identify what broke the trunk.  The version control tools allow's
>> everyone to continue working (by unmerging the offending commit).

> In the event you *do not* have a regular regression you may now
> understand why rule 1 is in place. Without it, any commit may break the
> trunk silently until the next guy performs a sim and nothing works
> anymore.

And this is the strength of distributed version control : rules 1 and 2 
are not mutually incompatible.

http://hginit.com/00.html for a rather (OK extremely!) biased account of 
the difference; any good links giving the reverse side of the story?

(Mercurial, but Git is similar)

You clone the trunk into a local repo, where you checkin broken code as 
often as you want. At last, when you are done and the new feature is 
working, you have a consistent set of changes you can push back to the 
trunk without breaking it.

If someone else has pushed to the trunk, you end up with two heads in the 
trunk, which require merging. Which isn't too bad in Mercurial but 
occasionally involves manual intervention.

The simplest way to deal with this, I find, is to *pull* the new head 
from the trunk, merge locally, re-test your change, then push. 

(Yes you can branch as well, and I do that for stable versions, i.e. 
releases, but cloning the repo is the most convenient way to branch).

- Brian

Article: 156402
Subject: Lattice MachXO3L - is it available anywhere ?
From: Brane2 <brankob@avtomatika.com>
Date: Sat, 29 Mar 2014 11:23:18 -0700 (PDT)
Links: << >>  << T >>  << A >>
I've downloaded documetnation on lower part of newcomers - MachXO3.

New Diamnond 3.1 has support for chips, but I can't find chips anyhwere. 

I tried Farnell and Mouser and couple of other adresses, but so far can't find anything.


Had anyone managed to spot any MachXO3L model being actually offered ?

Article: 156403
Subject: Re: Lattice MachXO3L - is it available anywhere ?
From: Brane2 <brankob@avtomatika.com>
Date: Sat, 29 Mar 2014 11:40:30 -0700 (PDT)
Links: << >>  << T >>  << A >>
Nevermind that.

Have found them at Digikey. They were "hidden" as CPLDs, so I haven't found them previously.

Prices seem a bit insane, but so are their prices for MachXO2, so I suppose these will get to Mouser these days for some normal price.


Article: 156404
Subject: Sending and receiving of 10GBASE-R Ethernet frames via GTX
From: wzab01@gmail.com
Date: Sat, 29 Mar 2014 13:30:13 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hi,

I'm working on a code which is supposed to send and receive 10GBASE-R Ethernet frames via SFP+ modules connected to the GTX transceiver in a Kintex-7 FPGA.

I've read the section 4 of 802.3-2012 standard and the ug476_7Series_Transceivers.pdf, but it still unclear to me how to send the correct Ethernet frame, directly driving the TX Gearbox of the GTX...

As the core is supposed to be used in an Open Source project, I'd like to avoid using the 10-Gigabit Ethernet PCS/PMA available from Xilinx.

I'll appreciate any hints...
-- 
Thank you in advance,
Wojtek

Article: 156405
Subject: Re: Xilinx ISERDESE2 deserializer primitive behaviour
From: Carl <carwer0@gmail.com>
Date: Sat, 29 Mar 2014 16:09:11 -0700 (PDT)
Links: << >>  << T >>  << A >>
> I may be missing something, but if there is no training pattern then surely all alignments are equally valid.
> 
> If not, then you need to specify how you know when the alignment is correct.
> 
> Then take the ISERDES output, apply the specified algorithm, and (if necessary) shift the ISERDES output appropriately.

As I wrote, I do have a frame clock which specifies the alignment.

(The concept of a frame clock: the frameClock:dataClock ratio is equal to the width of the parallel words. Coinsiding rising edges of the data and frame clocks assigns the current serial bit to either end of the parallel word.)

Article: 156406
Subject: Re: Xilinx ISERDESE2 deserializer primitive behaviour
From: Gabor <gabor@szakacs.org>
Date: Sun, 30 Mar 2014 10:43:20 -0500
Links: << >>  << T >>  << A >>
On 3/28/2014 10:46 AM, Carl wrote:
> Thanks for comments.
>
> Yes, it does seem like there's no good solution for this (when no training pattern is available).
>
> Good ideas from Gabor and Lasse about deserialising the frame clock. However, in my case, the data and the frame clock would come from different ports on the ISERDESE2 (DDLY and D respectively) since the data comes from a pad through an IDELAY and the frame clock comes from an MMCM. I don't know if I can then fully trust the deserialised data to be in phase.
>
> I decided to drop the ISERDES and do my deserialiser in logic instead. A pity I can't use the silicon resources though; a deterministic behaviour of the primitive, and it being documented, would have been enough.
>

I had an issue like this in Virtex 5, where the output of the IDELAY
could either route to a global clock as a route-through or to an
input flop as a delay element.  I worked around this (this was for
LVDS intput) by using an IBUFDS_DIFFOUT and deserializing the inverted
output while using the non-inverted output to feed the PLL.

Note that the phase going to the PLL is no longer important if you
are going to deserialize the clock to find the proper sampling
phase.  The important thing is to use the same input delay element
for the clock to ISERDES as the data to ISERDES paths.

-- 
Gabor

Article: 156407
Subject: Re: [cross-post][long] svn workflow for fpga development
From: al.basili@gmail.com (alb)
Date: 30 Mar 2014 22:07:09 GMT
Links: << >>  << T >>  << A >>
Hi Tom, (I'm answering reposting to vhdl as well to keep the thread 

cross-posted)

Tom Gardner <spamjunk@blueyonder.co.uk> wrote:
[]
>> In the past I've always followed two simple rules:
>>   1. never break the trunk
>>   2. commit often
> 
> So, what do you put on the trunk and what's on the branches?

The trunk has only merges from the branches [1]. When you start a 
project from scratch you certainly need to start from the trunk, but 
that situation lasts a very small amount of time (few days if not less) 
and as soon as possible you branch from it.

Branches are - only - for two reasons [2]:

1. adding features
2. removing bugs/problems

both of them start from the trunk and both of them should merge back in 
the trunk.

> One strategy which works for some types of system and
> some ways of team working is:
>   - to have the trunk for development

Is the trunk always functioning? If this is the case it cannot be really 
for development since every commit should be done only when the whole 
changeset is working (tested).

>   - whenever you reach a milestone of some sort,
>     create a branch containing the milestone

this is what I call 'tagging'. Yes it is a branch, but its purpose is to 
freeze the status of your development at some known state. These tags 
are essential when multiple repositories are pointing at each other for 
the purpose of reuse. You can point to version 1.2.3 and stick to it or 
follow its evolution to whatever version.

>   - whenever the regression tests have passed,
>     check in to the trunk (hopefully frequently)

so the regression test are run from your local copy? or from the 
branches? I think I missed this part.

>   - if it is necessary to save when regression
>     tests have not been passed, checkin to a branch

uhm...at this point you branched to fix something while the trunk is 
being developed. When do you decide that is time to merge back into the 
trunk?

> 
> Thus
>   - the head of the trunk always contains the latest
>     working system.

This contraddicts your earlier statement or I might have misunderstood 
what you mean by keeping the trunk for development. If no one pair of 
consecutive commits breaks the trunk than we are on the same page, but 
while I'm suggesting to branch and therefore commit even if you break 
something, you are suggesting that noone should commit to the trunk 
unless her/his piece is working (system wise).

>   - significant historical waypoints can be found on
>     a branch

Yes, including the ones that broke your regression tests...

[1] The only one exception is for modifications which are straight 
forward and do not require more than few minutes of work.

[2] refactoring is more delicate since it requires a solid regression 
suite in place to be sure that functionality is not affected

Article: 156408
Subject: Re: [cross-post][long] svn workflow for fpga development
From: al.basili@gmail.com (alb)
Date: 30 Mar 2014 22:07:39 GMT
Links: << >>  << T >>  << A >>
Hi Chris,
Chris Higgs <chiggs.99@gmail.com> wrote:
[]
>> If you find this flow somehow lacking important features and/or missing 
>> completely essential points which are relevant to fpga development flow 
>> I'd appreciate if you could share your thoughts.
> 
> Why on earth would anybody still be using SVN? It's over a decade old, 
> all of the issues you mention have been more than adequately solved by 
> distributed version control systems (for example git and mercurial). 

I think this graph does answer your question:
http://www.ohloh.net/repositories/compare

> It's
> perfectly possible to migrate an SVN repository into git and maintain the
> history.  If your engineers aren't willing to learn a new tool or your 
> company structure makes it impossible to effect such changes then you have
> bigger problems than just your choice of version control software!

'Living is easy with eyes closed' - John Lennon (Amen!)

> If you haven't already seen it you should watch Linus's tech-talk on 
> Git[1] which gives a good explanation of why choosing a non-distributed
> version control system is nonsensical.  EDA is conservative but this was
> almost 7 years ago, the approach has been well proven and widely adopted,
> there's no good reason for us not to move forward.

Behind conservative enterprises there are conservative managers by 
choice and/or by nature, but this is not the whole story! Some fields 
are more conservative than others (defense, aerospace, ...). A 
distributed version control while more attractive for its rich sets of 
features it may scare away whoever feels the lack of control behind it.

The Cathedral vs. the Bazaar' is a nice essay by E. Raymond, but its 
advocacy for the bazaar style that brought the *nix community where it is 
nowadays does not necessarily apply in a much more controlled regime 
like you may have on a project for the Department of Defense.

> Regarding regressions - you should really have a suite of quick-running
> tests that run every check-in, ideally that run in under a minute.  I run
> block-level simulations using Jenkins that achieve 100% coverage in 10s
> of seconds.  Quick feedback is essential and it's well worth investing
> effort in ensuring you have some tests that run quickly and tell you with
> at least some confidence that the system isn't completely broken.  With
> freely available tools such as Jenkins, there's no excuse for not having
> tests running automatically, e-mail notifications going out to anybody who
> broke the build etc.

I fully agree with you here, that would be my next item on my personal 
agenda...but revolutionary change requires time and patience ;-).

The main problem I see currently is the lack of 'command line' mindset 
in the designers mindset. They are all too used to graphical interfaces 
and manual wave tracing (sigh!). I suspect it is an habit related to the 
complexity they used to handle, which does not fit well nowadays systems.

Together with building a regression environment we should train people 
on a different verification model and workflow. Anyhow Continuous 
Integration is built around version control, so I need to get this fixed 
before moving on.

> In short, we should be adopting development practices that the software
> world has been using successfully for years.  RTL development is really
> just software a niche form of software development, we're just incredibly
> slow to realise it and capitalise on their experience and tools.

I agree here as well, but the software development world has an 
infrastructure around it that hardware designers unfortunately do not 
have. On my *nix box I can install nearly any type of software in a 
matter of seconds, look at the sources, discuss with the authors and 
benefit of a storm of developers who are constantly improving the 
quality of these product. They sell support and make a living out of it.

<rant mode> In the hardware world instead we close everything, live 
behind patrolled fences and sustain licensing policies which are close 
to insanity, essentially limiting progress and fair competition. 
</rant mode>

Al


Article: 156409
Subject: Re: [cross-post][long] svn workflow for fpga development
From: Tom Gardner <spamjunk@blueyonder.co.uk>
Date: Mon, 31 Mar 2014 01:02:52 +0100
Links: << >>  << T >>  << A >>
On 30/03/14 23:07, alb wrote:
> Hi Tom, (I'm answering reposting to vhdl as well to keep the thread
Thanks; I don't subscribe to that and my reader won't let me
cross-post to a group to which I'm not subscribed.

>
> cross-posted)
>
> Tom Gardner <spamjunk@blueyonder.co.uk> wrote:
> []
>>> In the past I've always followed two simple rules:
>>>    1. never break the trunk
>>>    2. commit often
>>
>> So, what do you put on the trunk and what's on the branches?
>
> The trunk has only merges from the branches [1].

The key is continuous incremental integration checked by
solid comprehensive automated tests.

My problem with your statement is that I don't agree with [1].
Merges of any kind require regression testing before re-merging.
The issue then become if your merge conflicts with another merge.

That is trapped by having a *continual* background automated
build and regression test on the head of the trunk. When a merge
causes a failure, it is picked up quickly. Traditionally there is a
screen visible to everybody that shows the build status as red
or green. Collective groans are emitted when it becomes red,
and sponge balls may be thrown at the perpetrator - who keeps
the balls ready to throw at the next malefactor :)

Since failure is picked up quickly, it is usually easy to
determine what caused the failure, and to correct it.

That's a damn sight easier to deal with than the major
inconsistencies that creep in if merging/re-integration
only occur occasionally.

The major danger is that seeing a green status light can
lull the unwary into thinking that there are no problems.
Naturally the "quality" of the greenness is completely
dependent on the quality of the tests.


> When you start a
> project from scratch you certainly need to start from the trunk, but
> that situation lasts a very small amount of time (few days if not less)
> and as soon as possible you branch from it.
>
> Branches are - only - for two reasons [2]:

In my experience [2] (i.e. refactoring) is the tail that wags this dog.
But all development can be regarded as refactoring, e.g. refactoring
an unimplemented feature into a functioning feature.


> 1. adding features
> 2. removing bugs/problems
>
> both of them start from the trunk and both of them should merge back in
> the trunk.

Agreed, but I don't see the benefit of a branch in that process.
Trunk->workspace->trunk.


>> One strategy which works for some types of system and
>> some ways of team working is:
>>    - to have the trunk for development
>
> Is the trunk always functioning? If this is the case it cannot be really
> for development since every commit should be done only when the whole
> changeset is working (tested).

Yes, and yes.

The head of the trunk is frequently re-built and re-tested in its
entirety - continuous incremental integration and regression testing.


>>    - whenever you reach a milestone of some sort,
>>      create a branch containing the milestone
>
> this is what I call 'tagging'. Yes it is a branch, but its purpose is to
> freeze the status of your development at some known state. These tags
> are essential when multiple repositories are pointing at each other for
> the purpose of reuse. You can point to version 1.2.3 and stick to it or
> follow its evolution to whatever version.

Agreed.


>>    - whenever the regression tests have passed,
>>      check in to the trunk (hopefully frequently)
>
> so the regression test are run from your local copy? or from the
> branches? I think I missed this part.

On your local copy whenever convenient for you,
and continually on the head of the trunk.


>>    - if it is necessary to save when regression
>>      tests have not been passed, checkin to a branch
>
> uhm...at this point you branched to fix something while the trunk is
> being developed. When do you decide that is time to merge back into the
> trunk?

Whenever convenient for you. Preferably merge to the trunk
several times a day.

Since the deltas are small there are unlikely to be
major problems; when there occur there are not many
places where the culprit could be.


>> Thus
>>    - the head of the trunk always contains the latest
>>      working system.
>
> This contraddicts your earlier statement or I might have misunderstood
> what you mean by keeping the trunk for development. If no one pair of
> consecutive commits breaks the trunk than we are on the same page, but
> while I'm suggesting to branch and therefore commit even if you break
> something, you are suggesting that noone should commit to the trunk
> unless her/his piece is working (system wise).

Correct. Why save and publish something that is broken?


>>    - significant historical waypoints can be found on
>>      a branch
>
> Yes, including the ones that broke your regression tests...

Those should only be in your private workspace.


> [1] The only one exception is for modifications which are straight
> forward and do not require more than few minutes of work.

Ah, the infamous "this change is so small it can't
possibly break anything"!


> [2] refactoring is more delicate since it requires a solid regression
> suite in place to be sure that functionality is not affected

All development is refactoring.



Article: 156410
Subject: Re: Lattice MachXO3L - is it available anywhere ?
From: rickman <gnuarm@gmail.com>
Date: Mon, 31 Mar 2014 12:56:03 -0400
Links: << >>  << T >>  << A >>
On 3/29/2014 2:40 PM, Brane2 wrote:
> Nevermind that.
>
> Have found them at Digikey. They were "hidden" as CPLDs, so I haven't found them previously.
>
> Prices seem a bit insane, but so are their prices for MachXO2, so I suppose these will get to Mouser these days for some normal price.

Not sure what you think of as "insane" prices.  What FPGAs do you find 
much lower than $10 at quantity 1?  This seems to be what I have been 
paying for 3kLUT XP parts.  I did a survey a few months ago and didn't 
find much that was cheaper.

-- 

Rick

Article: 156411
Subject: Re: lattice Diamond on Linux - programming doesn't work...
From: rickman <gnuarm@gmail.com>
Date: Mon, 31 Mar 2014 12:58:01 -0400
Links: << >>  << T >>  << A >>
On 3/28/2014 6:40 PM, Brane2 wrote:
> Dne petek, 28. marec 2014 10:22:22 UTC je oseba Brane2 napisala:
>
>> <SNIP>
>> So, if anyone has an idea, it is welcome.
>
> Update - it works now.
>
> Main part of the reason is that Microchip's MPLABX decided to install its own version of libusb in /usr/local/lib and dynamic loader was picking this hacked version instead system's official one.
>
> I deleted it and now it works. At least Diamond bundle.
>
>
> Standalone programmer package still criaks but that is due to missing libraries. It seems it is missing at least libpng12.so.
>
> But this is fixable in relatively simple way. Totally same programmer utility is within Diamond, where it works.
>
>
> Looking around for solution, I've found totally old Lattice's programming cable for parallel port. It's dead simple- electronics contains only 74HC367 buffer and a couple of resistors.
>
> And it seems that it is the same thing as current parallel port ISP cable from Lattice.
>
> I'm about to try it with Diamond on that MachXO2 breakout board...

Glad you got this working.  Let us know if the parallel cable works for 
you too.

-- 

Rick

Article: 156412
Subject: Re: lattice Diamond on Linux - programming doesn't work...
From: Brane2 <brankob@avtomatika.com>
Date: Mon, 31 Mar 2014 12:32:13 -0700 (PDT)
Links: << >>  << T >>  << A >>
Dne ponedeljek, 31. marec 2014 16:58:01 UTC je oseba rickman napisala:

> Glad you got this working.  Let us know if the parallel cable works for 
> 
> you too.
> 
> 
> 
> -- 
> 
> 
> 
> Rick

Nope. It seems I have killed an FPGA with it.

It really would help if there was a simple schematics of the latest parallel cable.

And it doesn't seem programmer util from diamond recognises it.

I had to muck around with ispVM, which is old and I had to chase obsolete old libraries all over the net for it and when I found them, I couldn't check that tehy work good on my system besides obvious dynamic linking check with ldd.

In the end, program has kind of started, but I couldn't detect cable. And I burned the FPGA while trying.

One of the possible reasons might be that I had parallel port + 2 x serial ports on PCI card, which got mapped in memory, not through I/O ports ( reported memory localtion of parallel port region was 0xe000 instead of "classic" I/O port ).

When autodetecting, progam has set address to 0xe000, but then it couldn't do anything with it.

Since I now had the way to program the chip, I stopped playing with the cable.

It would b interesting to finish the job had  I got the schematics ( asuming it is simple, like most parallel port cables) and in case bundled programmer util would work with it.

Or even better, something open source that I could compile for my system and debug with less pain...















Article: 156413
Subject: Re: Lattice MachXO3L - is it available anywhere ?
From: Brane2 <brankob@avtomatika.com>
Date: Tue, 1 Apr 2014 07:43:44 -0700 (PDT)
Links: << >>  << T >>  << A >>
Dne ponedeljek, 31. marec 2014 16:56:03 UTC je oseba rickman napisala:

> Not sure what you think of as "insane" prices.  What FPGAs do you find 
> 
> much lower than $10 at quantity 1? 


I don't remeber exact numbers, but I remmeber that prieces were unusually high.
So I checked their prices for MachXO2, which I could compare to Mouser's and from this I concluded that main reason is Digikey's higher provisions, not Lattice's pricing policy.


BTW, Mouser has ice40 with 3520 LUTS for $6.2 for 1, which drops under $5 at 50 pcs... Not exactly MachXO3, but could be enough for many applications...



Article: 156414
Subject: Re: Lattice MachXO3L - is it available anywhere ?
From: rickman <gnuarm@gmail.com>
Date: Tue, 01 Apr 2014 11:34:41 -0400
Links: << >>  << T >>  << A >>
On 4/1/2014 10:43 AM, Brane2 wrote:
> Dne ponedeljek, 31. marec 2014 16:56:03 UTC je oseba rickman napisala:
>
>> Not sure what you think of as "insane" prices.  What FPGAs do you find
>>
>> much lower than $10 at quantity 1?
>
>
> I don't remeber exact numbers, but I remmeber that prieces were unusually high.
> So I checked their prices for MachXO2, which I could compare to Mouser's and from this I concluded that main reason is Digikey's higher provisions, not Lattice's pricing policy.
>
>
> BTW, Mouser has ice40 with 3520 LUTS for $6.2 for 1, which drops under $5 at 50 pcs... Not exactly MachXO3, but could be enough for many applications...

Er, I still haven't gotten used to the updated T-bird controls... so you 
will get a copy of this to your email as well.

Just remember that unlike the other Lattice non-volatile products, the 
ice40 line is NOT flash but rather one time programmable.  It still has 
RAM so you can always load it from external memory I believe.

-- 

Rick

Article: 156415
Subject: ip address of fpga
From: MOOSA IRSHAD <moosairshad@gmail.com>
Date: Wed, 2 Apr 2014 01:28:51 -0700 (PDT)
Links: << >>  << T >>  << A >>
what is an ip addres of fpga...


my staff hav given me paper regarding security for ip address  of fpga using watermarking in look up table...

but i cant understandmuch about it since i lack basics on fpga... hope somebody will help me..


with regards 

Article: 156416
Subject: Any good reference works on serial buses?
From: chthon <jurgen.defurne@gmail.com>
Date: Wed, 2 Apr 2014 22:50:05 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hi all,

I would like to understand and experiment with serial buses and protocols inside an FPGA (like AXI). Is there any reference work that you can recommend?

Regards,

Jurgen

Article: 156417
Subject: Simulation deltas
From: Carl <carwer0@gmail.com>
Date: Thu, 3 Apr 2014 06:01:34 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hi,

This question deals both with an actual problem, and with some more concept=
ual thoughts on simulation deltas and how an RTL entity should behave with =
regards to this.

This post regards the case of a simulation with ideal time - that is, no de=
lays (in time) modelled, rather trusting only simulation deltas for the ord=
ering of events.


*Conceptual*

I would argue that for a well-behaved synchronous RTL entity, the following=
 must be true:

*All readings of the input ports must be made *on* the delta of the rising =
flank of the clock - not one or any other number of deltas after that.*

Would people agree on that?

It follows from the possibility of other logic, hierarchically above the en=
tity in question, altering the input ports as little as one delta after the=
 rising flank. That must be allowed.


*My actual problem*

After a lot of debugging of one of my simulations, I found a Xilinx simulat=
ion primitive (IDELAYE2 in Unisim) *not* adhering to the statement in the p=
revious section, which had caused all the problems.

See the signals plotted here:
http://www.fpga-dev.com/misc/deltaDelayProblem.png

It's enough to focus on the "ports" section. The ports are:
- c: in, the clock
- cntValueIn: in
- ld: in, writeEnable for writing cntValueIn to an internal register
- cntValueOut: out, giving the contents of that register

As can be seen, my 'ld' operation is de-asserted one delta after the rising=
 flank. I argue this should be OK, but it is obvious that the data is never=
 written (cntValueOut remains 0). If I delay the de-assertion of 'ld' just =
one more delta, the write *does* take effect as desired.

I would argue this is a (serious) flaw of the Xilinx primitive. Would peopl=
e agree on that as well?


(The following is not central for the above discussion, may be skipped.)

I have checked the actual reason for the problem. See the "internals" secti=
on of the signals. First, Xilinx delays both the clock and the ports to the=
 *_dly signals. Fully OK, if from now on operating on the delayed signals. =
The problem is that the process writing to the internal register is not clo=
cked by c_dly, but by another signal, c_in, which is delayed *one more* del=
ta. This causes my requested 'ld' to be missed. (c_in is driven from c_dly =
in another process, inverting the the clock input if the user has requested=
 that.)

I argue that synchronous entities must be modelled in such a way that all p=
rocesses reading input ports *must* be clocked directly by the input clock =
port - not by some derived signal that is lagging (if only by one delta). I=
f this is not possible, the input ports being read must be delayed accordin=
gly. In this case, if Xilinx wishes to conditionally invert the clock like =
this, causing another delta of delay, the input ports must also be delayed =
the corresponding number of deltas.


Cheers,
Carl

Article: 156418
Subject: Re: Simulation deltas
From: KJ <kkjennings@sbcglobal.net>
Date: Thu, 3 Apr 2014 06:24:49 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Thursday, April 3, 2014 9:01:34 AM UTC-4, Carl wrote:
> *Conceptual*=20
>=20
> I would argue that for a well-behaved synchronous RTL entity, the followi=
ng=20
> must be true:=20
>=20
> *All readings of the input ports must be made *on* the delta of the risin=
g=20
> flank of the clock - not one or any other number of deltas after that.*=
=20
>=20
> Would people agree on that?=20
>=20

I would not agree, conceptual reasoning is as follows:
- The clock causes something to happen
- Something that causes 'something else' to happen must precede 'something =
else' because this is a causal world we live in.

> It follows from the possibility of other logic, hierarchically above the =
entity=20
> in question, altering the input ports as little as one delta after the ri=
sing=20
> flank. That must be allowed.=20
>=20
Hierarchy does not alter signals.  You can go through as many levels of hie=
rarchy as you want and it will not change the time (including simulation de=
lta time) that a signal changes.  What *will* change that time are statemen=
ts such as 'clk_out <=3D clk_in' but that is because a new signal called 'c=
lk_out' has been created and that is *not* the same thing as 'clk_in'...sin=
ce we live in a causal world, 'clk_out' must occur after 'clk_in'.  Granted=
 a synthesizer will ignore optimize the statement and just use 'clk_in' whe=
rever 'clk_out' goes, but that is a different tangent than what you're aski=
ng.

Kevin Jennings

Article: 156419
Subject: Re: Simulation deltas
From: Carl <carwer0@gmail.com>
Date: Thu, 3 Apr 2014 07:42:56 -0700 (PDT)
Links: << >>  << T >>  << A >>
Den torsdagen den 3:e april 2014 kl. 15:24:49 UTC+2 skrev KJ:
> On Thursday, April 3, 2014 9:01:34 AM UTC-4, Carl wrote:
> >
> > I would argue that for a well-behaved synchronous RTL entity, the follo=
wing=20
> > must be true:=20
> >
> > *All readings of the input ports must be made *on* the delta of the ris=
ing=20
> > flank of the clock - not one or any other number of deltas after that.*=
=20
> >
> > Would people agree on that?=20
>=20
> I would not agree, conceptual reasoning is as follows:
> - The clock causes something to happen
> - Something that causes 'something else' to happen must precede 'somethin=
g else' because this is a causal world we live in.

I don't really get what your two points mean in this context. I do understa=
nd and agree on the literal meaning of them.

I don't think those points necessariyl adress my issue. My issue doesn't on=
ly relate to causality. Then main problem is to determine *exactly when som=
ething is sampled*.

Since you don't agree with the statement however; how then should synchrono=
us elements communicate with each other? If I clock a unit with 'clk', and =
I can't expect that unit to sample the input ports (which I drive) on (exac=
tly on, without any delta delays) the rising edge of 'clk', then how long a=
fter the edge must I hold the input data stable? One delta? Two, ten? One p=
s, one ns?

(If the answer is anything more than deltas, e.i. involving time, we are no=
 longer in functional modelling, which was an assumption for this question.=
)

Or how would you suggest the problem I illustrated should be avoided?


> > It follows from the possibility of other logic, hierarchically above th=
e entity=20
>=20
> > in question, altering the input ports as little as one delta after the =
rising=20
>=20
> > flank. That must be allowed.=20
>=20
> Hierarchy does not alter signals.  You can go through as many levels of h=
ierarchy as you want and it will not change the time (including simulation =
delta time) that a signal changes.  What *will* change that time are statem=
ents such as 'clk_out <=3D clk_in' but that is because a new signal called =
'clk_out' has been created and that is *not* the same thing as 'clk_in'...s=
ince we live in a causal world, 'clk_out' must occur after 'clk_in'. =20

Well of course I agree on all that. This is not about hierarchy. Maybe that=
 was bad wording by me. This is about how you should expect functional, syn=
chronous elements (possibly developed by others) to behave.

> Granted a synthesizer will ignore optimize the statement and just use 'cl=
k_in' wherever 'clk_out' goes, but that is a different tangent than what yo=
u're asking.

Yes, that's something else. A synthesis tools knows about the clocks and si=
gnals and warns for any setup/hold time violations. My question regards ide=
al functional models. Ideal and functional in the sens that delays are not =
modelled (rather trusting the delta's to keep track of event ordering). If =
delays would be modelled as well, these problems would not arise.

Article: 156420
Subject: Digilent Drivers stuck with Fedora 20
From: luudee <rudolf.usselmann@gmail.com>
Date: Thu, 3 Apr 2014 09:03:32 -0700 (PDT)
Links: << >>  << T >>  << A >>


OK, I know Fedora 20 is not officially suported ....

But, the install goes through just fine. I don't see any errors, I went through all 
docs, and everything looks good. Udev is running and the settings all look good.

Impact starts without any erros, and than just hangs:
Release 14.7 - iMPACT P.20131013 (lin64)
Copyright (c) 1995-2013 Xilinx, Inc. All rights reserved.
Preference Table
Name Setting 
StartupClock Auto_Correction 
AutoSignature False 
KeepSVF False 
ConcurrentMode False 
UseHighz False 
ConfigOnFailure Stop 
UserLevel Novice 
MessageLevel Detailed 
svfUseTime false 
SpiByteSwap Auto_Correction 
AutoInfer false 
SvfPlayDisplayComments false 
>>INFO:iMPACT - Digilent Plugin: Plugin Version: 2.4.3


Any ideas suggestions ?

linusb and libftdi are installed, latest digilent driver is sinstalled as well.

Any ideas/suggestions appreciated ....

Thanks,
rudi



Article: 156421
Subject: Re: Sending and receiving of 10GBASE-R Ethernet frames via GTX
From: wzab01@gmail.com
Date: Thu, 3 Apr 2014 09:57:01 -0700 (PDT)
Links: << >>  << T >>  << A >>
W dniu sobota, 29 marca 2014 21:30:13 UTC+1 u=C5=BCytkownik wza...@gmail.co=
m napisa=C5=82:
> Hi,
>=20
> I'm working on a code which is supposed to send and receive 10GBASE-R Eth=
ernet frames via SFP+ modules connected to the GTX transceiver in a Kintex-=
7 FPGA.
>=20
> I've read the section 4 of 802.3-2012 standard and the ug476_7Series_Tran=
sceivers.pdf, but it still unclear to me how to send the correct Ethernet f=
rame, directly driving the TX Gearbox of the GTX...
>=20
> As the core is supposed to be used in an Open Source project, I'd like to=
 avoid using the 10-Gigabit Ethernet PCS/PMA available from Xilinx.
>=20

OK. I've got it. Everything is Table 49-7, on page 266 in 802.3-2008_sectio=
n4.pdf, available from http://standards.ieee.org/getieee802/download/802.3-=
2012_section4.pdf

Of course one must also consider "pauses" required by the gearboxes impleme=
nted
by the GT Wizard (as described in "TX Gearbox" and "RX Gearbox" sections in=
 the ug476 7 Series FPGAs GTX/GTH Transceivers User Guide)

Regards,
Wojtek

Regards,
Wojtek

Article: 156422
Subject: Re: Simulation deltas
From: KJ <kkjennings@sbcglobal.net>
Date: Thu, 3 Apr 2014 10:17:05 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Thursday, April 3, 2014 10:42:56 AM UTC-4, Carl wrote:
> I don't really get what your two points mean in this context. I do unders=
tand=20
> and agree on the literal meaning of them.=20
>=20
> I don't think those points necessariyl adress my issue. My issue doesn't =
only=20
> relate to causality. Then main problem is to determine *exactly when some=
thing=20
> is sampled*.=20
>=20
> Since you don't agree with the statement however; how then should synchro=
nous=20
> elements communicate with each other? If I clock a unit with 'clk', and I=
 can't=20
> expect that unit to sample the input ports (which I drive) on (exactly on=
,=20
> without any delta delays) the rising edge of 'clk', then how long after t=
he=20
> edge must I hold the input data stable? One delta? Two, ten? One ps, one =
ns?=20
>=20
Actually, I misread a bit your actual question, I do agree that inputs shou=
ld get sampled on only one simulation delta cycle...and they do.  For some =
reason, I thought you were talking about outputs being generated.

In any case, your conceptual question doesn't relate to the problem that yo=
u are seeing with the Xilinx primitive.  I have no idea whether it correctl=
y models the primitive or not, but let's assume for a moment that it is cor=
rect.  Since that primitive is attempting to model reality, there very well=
 would be a delay between the input clock to that primitive and when that p=
rimitive actually samples input signals. If that is the situation, then inp=
uts must also model reality in that they cannot be changing instantaneously=
 either.  Inputs to such a model must meet the setup/hold constraints of th=
e design.

When you're performing functional simulation, there can be an assumption th=
at you can ignore setup/hold time issues.  This is an invalid assumption if=
 you include parts into your model that model reality where delays do occur=
.  The model is not wrong in that case, it is your usage of that model.

Just like on a physical board, on the input side to such a model, you need =
to insure that you do not violate setup or hold constraints.  If you do, th=
en a physical board will not always work, in a simulation environment your =
simulation will fail (which is what you're experiencing).  On the output si=
de of a model, you need to make sure that you're not sampling too early (i.=
e. sooner than the Tco min).

Kevin Jennings

Article: 156423
Subject: Re: Simulation deltas
From: GaborSzakacs <gabor@alacron.com>
Date: Thu, 03 Apr 2014 14:35:01 -0400
Links: << >>  << T >>  << A >>
KJ wrote:
> On Thursday, April 3, 2014 10:42:56 AM UTC-4, Carl wrote:
>> I don't really get what your two points mean in this context. I do understand 
>> and agree on the literal meaning of them. 
>>
>> I don't think those points necessariyl adress my issue. My issue doesn't only 
>> relate to causality. Then main problem is to determine *exactly when something 
>> is sampled*. 
>>
>> Since you don't agree with the statement however; how then should synchronous 
>> elements communicate with each other? If I clock a unit with 'clk', and I can't 
>> expect that unit to sample the input ports (which I drive) on (exactly on, 
>> without any delta delays) the rising edge of 'clk', then how long after the 
>> edge must I hold the input data stable? One delta? Two, ten? One ps, one ns? 
>>
> Actually, I misread a bit your actual question, I do agree that inputs should get sampled on only one simulation delta cycle...and they do.  For some reason, I thought you were talking about outputs being generated.
> 
> In any case, your conceptual question doesn't relate to the problem that you are seeing with the Xilinx primitive.  I have no idea whether it correctly models the primitive or not, but let's assume for a moment that it is correct.  Since that primitive is attempting to model reality, there very well would be a delay between the input clock to that primitive and when that primitive actually samples input signals. If that is the situation, then inputs must also model reality in that they cannot be changing instantaneously either.  Inputs to such a model must meet the setup/hold constraints of the design.
> 
> When you're performing functional simulation, there can be an assumption that you can ignore setup/hold time issues.  This is an invalid assumption if you include parts into your model that model reality where delays do occur.  The model is not wrong in that case, it is your usage of that model.
> 
> Just like on a physical board, on the input side to such a model, you need to insure that you do not violate setup or hold constraints.  If you do, then a physical board will not always work, in a simulation environment your simulation will fail (which is what you're experiencing).  On the output side of a model, you need to make sure that you're not sampling too early (i.e. sooner than the Tco min).
> 
> Kevin Jennings

Then perhaps the error in the xilinx case is that they are applying a
physical model when you call up a behavioral simulation.  I remember
that the BRAM models (at least for VHDL) had a similar issue causing
the behavioral simulation to look as if the readout was not registered
unless you had some delay on the address inputs.

-- 
Gabor

Article: 156424
Subject: Re: Any good reference works on serial buses?
From: Tim Wescott <tim@seemywebsite.really>
Date: Thu, 03 Apr 2014 13:58:34 -0500
Links: << >>  << T >>  << A >>
On Wed, 02 Apr 2014 22:50:05 -0700, chthon wrote:

> Hi all,
> 
> I would like to understand and experiment with serial buses and
> protocols inside an FPGA (like AXI). Is there any reference work that
> you can recommend?
> 
> Regards,
> 
> Jurgen

Asynchronous and SPI are dead easy -- any UART data sheet will pretty 
much give you all you need to know for asynchronous, and the data sheet 
for any SPI block in a microcontroller will give you what you need for 
SPI.

I2C is harder, but can be fairly easily bit-banged in a microprocessor, 
if you don't mind going slow.

CAN is harder yet -- you're into "buying IP is better" territory, unless 
you have some serious sales volume.  Ditto USB, although I know of some 
bit-banged USB examples on microprocessors (bit-banging USB is kind of my 
personal gold standard for easy -- if a hobbyist can bit-bang it, then it 
should be easy for you, unless they're ignoring all sorts of corners in 
the "real" spec).

-- 

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com




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