Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
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
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
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). - BrianArticle: 156402
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
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
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, WojtekArticle: 156405
> 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
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. -- GaborArticle: 156407
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 affectedArticle: 156408
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> AlArticle: 156409
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
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. -- RickArticle: 156411
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. -- RickArticle: 156412
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
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
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. -- RickArticle: 156415
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 regardsArticle: 156416
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, JurgenArticle: 156417
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, CarlArticle: 156418
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 JenningsArticle: 156419
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
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, rudiArticle: 156421
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, WojtekArticle: 156422
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 JenningsArticle: 156423
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. -- GaborArticle: 156424
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:
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