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
On 12/16/2014 11:52 PM, hamilton wrote: > On 12/16/2014 8:58 PM, rickman wrote: >> On 12/16/2014 5:34 PM, hamilton wrote: >>> On 12/16/2014 2:34 PM, rickman wrote: >>>> On 12/16/2014 1:07 PM, hamilton wrote: >>>>>>> On 12/15/2014 6:38 PM, Rick C. Hodgin wrote: <SNIP> >>>>> >>>>> WOW, another right wing nut case !! >>>>> >>>>> Hey Rick, when you go off the deep end will you find a chocolate >>>>> shop to >>>>> visit ?? >>>> >>>> Right wing? His comments were religious. The right wing label is >>>> political. What is the connection here? >>>> >>> http://www.salon.com/2014/02/22/reagans_christian_revolt_how_conservatives_hijacked_american_religion/ >>> >>> >> >> I'm sorry, but the fact that some people mix religion and politics does >> not mean *everyone* who believes in religion is a conservative >> politically. Likewise it does not mean everyone who is conservative >> politically is religious. >> > Lets see, you were wrong on Right Wing and religion, > and we see the right wing crack pots killing kids in Pakistan. > > Yes, those that need to proselytize to half the world and not keep their > whacked out ideas to themselves are just one step away from visiting > _your_ kids school. > > Religion has gone too far in its control of mind damaged people. > And there are lots out there to chose from. Whatever -- RickArticle: 157576
Antti, Sorry for digging out an old thread. Why is it not supported? M-PHY is 8B10B coded and embeds clock? Is it the low-rates that the FPGA transceiver won't support or are there some "IDLE" states or somethings that the GTs can't handle. Is it possible to "come up" in a high-rate and avoid the low-rates if this is the problem? Thanks, M >On Tuesday, 28 October 2014 12:18:33 UTC+1, mnentwig wrote: >> Hi, >> >> does anybody know whether it is possible (or impossible) to use an FPGA's >> serial transceivers for a MIPI type 2 M-PHY link (i.e. 1.5 GBit/s)? >> Xlinx' book http://www.xilinx.com/publications/archives/books/serialio.pdf >> makes it look easy, but I suspect this gets very difficult once moving away >> from an established standard. >> >> --------------------------------------- >> Posted through http://www.FPGARelated.com > >M-PHY is not supported > --------------------------------------- Posted through http://www.FPGARelated.comArticle: 157577
rickman <gnuarm@gmail.com> wrote: > A current probe measures current, not voltage. It is a pretty poor way > to measure signals. You can also capacitively couple signals into a probe, but you only get the higher frequencies due to the filtering effect. That might be OK for GHz signals, but not for DC. TheoArticle: 157578
rickman wrote: > > If you are talking about the circuit shown in your reference it will > still oscillate the same way as a gate based FF. Each inverter in the > loop produces a signal, one is Q the other is Q not whether it is > labeled as such or not. Oscillations happen. > OK, so clearly you didn't actually read the artical. 1) Those inverters in a loop are "latches" that work because there are exactly two inversions forming positive feedback. 2) There is no Q not as you would have in a cross-coupled gate flip-flop. i.e. the middle of each inverter pair is not accessible. In fact you could re-draw the schematics showing the pair as a single non-inverting buffer and it would not change the way the circuit works. There is no need for inversion to hold the current state. 3) Oscillations don't "happen." The most you'll get is two transitions when you go into metastability and eventually resolve to the original state (0 to 0 or 1 to 1). In any case, this thread is getting too old... As someone said in another recent thread: whatever -- GaborArticle: 157579
On 12/17/2014 3:47 PM, GaborSzakacs wrote: > rickman wrote: >> >> If you are talking about the circuit shown in your reference it will >> still oscillate the same way as a gate based FF. Each inverter in the >> loop produces a signal, one is Q the other is Q not whether it is >> labeled as such or not. Oscillations happen. >> > > OK, so clearly you didn't actually read the artical. > > 1) Those inverters in a loop are "latches" that work because > there are exactly two inversions forming positive feedback. Yes, two inverters in a loop. Bistable with delays in each element... that part is *exactly* the same as the cross coupled gates and this is *exactly* the feature that allows oscillations. > 2) There is no Q not as you would have in a cross-coupled gate > flip-flop. i.e. the middle of each inverter pair is not > accessible. Whether or not the inverted signal is brought out is irrelevant. If you don't like the name "Q not" tell me what you wish to call it. Then substitute that name in the explanation I gave and it still describes the functionality that will allow oscillations. > In fact you could re-draw the schematics showing > the pair as a single non-inverting buffer and it would not > change the way the circuit works. There is no need for inversion > to hold the current state. Again, you seem to think hiding the details changes operation of the circuit. There is no such thing as a non-inverting primitive element. A "non-inverting" buffer is two inverting buffers cascaded, each with delay. To get a non-inverting element requires either common drain or a common gate arrangement of the transistors which are not suitable for logic elements. > 3) Oscillations don't "happen." The most you'll get is two > transitions when you go into metastability and eventually > resolve to the original state (0 to 0 or 1 to 1). Yes, the thread is old as are the excuses for not properly analyzing the operation of the circuit. Try putting this in any simulator and testing it. If you change the data input at the right moment so that the first inverter output has changed at the moment the feedback gate closes the loop and the input gate disconnects the input, you will have two signals of incompatible polarity which will chase each other around the loop. In a simulator the oscillations will persist potentially forever. In the real world they will die out... but in an indeterminate time. Actually the time is determinate... if you can nail down all the variables, *but* the result relative to the variables such as the exact time of the input transition is very chaotic. In fact, if I can get an approximate model for the typical transistor used in modern digital logic I will run a simulation. If you just treat the circuit as a bunch of logical elements rather than electronics I can see where you would not properly understand the operation. You keep trying to explain the circuit with your view of it (which I have tried to explain how it is faulty), but you have not explained what is faulty about my view of the circuit. If you don't wish to discuss this further, that's fine. -- RickArticle: 157580
On Wed, 17 Dec 2014, rickman wrote: > On 12/17/2014 3:47 PM, GaborSzakacs wrote: > >> 3) Oscillations don't "happen." The most you'll get is two >> transitions when you go into metastability and eventually >> resolve to the original state (0 to 0 or 1 to 1). From my understanding, it does not oscillate - it simply tries to resolve and the lesser the initial voltage difference between the two nodes of the latch, the bigger the time constant. Any big swing to call it "oscillation" should put it out of the metastable state already. Could it be that the master latch does not oscillate, but during the time it being metastable (exponentially resolving), the slave (at that time transparent) due to indeterminate logic level and noises does the observed oscillation? This could be very misleading. That's for the flip-flop constructed with pass gates, which should be close to what is actually used these days (?). I have no direct ASIC experience. > Try putting this in any simulator and testing it. If you change the data > input at the right moment so that the first inverter output has changed at > the moment the feedback gate closes the loop and the input gate disconnects > the input, you will have two signals of incompatible polarity which will > chase each other around the loop. In a simulator the oscillations will > persist potentially forever. In the real world they will die out... but in > an indeterminate time. Actually the time is determinate... if you can nail > down all the variables, *but* the result relative to the variables such as > the exact time of the input transition is very chaotic. In fact, if I can > get an approximate model for the typical transistor used in modern digital > logic I will run a simulation. Rick, if you happen to make such simulation, please share the results. One of the more interesting threads.Article: 157581
Vladimir Ivanov wrote: > > On Wed, 17 Dec 2014, rickman wrote: > >> On 12/17/2014 3:47 PM, GaborSzakacs wrote: >> >>> 3) Oscillations don't "happen." The most you'll get is two >>> transitions when you go into metastability and eventually >>> resolve to the original state (0 to 0 or 1 to 1). > > From my understanding, it does not oscillate - it simply tries to > resolve and the lesser the initial voltage difference between the two > nodes of the latch, the bigger the time constant. Any big swing to call > it "oscillation" should put it out of the metastable state already. > > Could it be that the master latch does not oscillate, but during the > time it being metastable (exponentially resolving), the slave (at that > time transparent) due to indeterminate logic level and noises does the > observed oscillation? This could be very misleading. > > That's for the flip-flop constructed with pass gates, which should be > close to what is actually used these days (?). I have no direct ASIC > experience. > >> Try putting this in any simulator and testing it. If you change the >> data input at the right moment so that the first inverter output has >> changed at the moment the feedback gate closes the loop and the input >> gate disconnects the input, you will have two signals of incompatible >> polarity which will chase each other around the loop. In a simulator >> the oscillations will persist potentially forever. In the real world >> they will die out... but in an indeterminate time. Actually the time >> is determinate... if you can nail down all the variables, *but* the >> result relative to the variables such as the exact time of the input >> transition is very chaotic. In fact, if I can get an approximate >> model for the typical transistor used in modern digital logic I will >> run a simulation. > > Rick, if you happen to make such simulation, please share the results. > > One of the more interesting threads. There are a bunch of simulations in the document. None of them oscillate. ByeArticle: 157582
I've heard the same, that the low-rate mode is one problem. Don't think you can bring up the interface in HSx mode in a standardized way (product-specific "hacks" via some 3-wire interface etc could still work). I wonder whether one could reconfigured the line drivers "on-the-fly" and drive the low speed mode from the FPGA fabric, bypassing the SERDES etc hardware blocks. --------------------------------------- Posted through http://www.FPGARelated.comArticle: 157583
On Friday, 19 December 2014 10:23:47 UTC+1, mnentwig wrote: > I've heard the same, that the low-rate mode is one problem. Don't think you > can bring up the interface in HSx mode in a standardized way > (product-specific "hacks" via some 3-wire interface etc could still work). > I wonder whether one could reconfigured the line drivers "on-the-fly" and > drive the low speed mode from the FPGA fabric, bypassing the SERDES etc > hardware blocks. > > --------------------------------------- > Posted through http://www.FPGARelated.com the low-speed can be patched in if desired. for some reason I did think there are more complications ..Article: 157584
>On Friday, 19 December 2014 10:23:47 UTC+1, mnentwig wrote: >> I've heard the same, that the low-rate mode is one problem. Don't think you >> can bring up the interface in HSx mode in a standardized way >> (product-specific "hacks" via some 3-wire interface etc could still work). >> I wonder whether one could reconfigured the line drivers "on-the-fly" and >> drive the low speed mode from the FPGA fabric, bypassing the SERDES etc >> hardware blocks. >> >> --------------------------------------- >> Posted through http://www.FPGARelated.com > >the low-speed can be patched in if desired. >for some reason I did think there are more complications .. > Does M-PHY "turn-off" transmission and expect a fast wake-up time? The FPGA transceivers and related PLLs would take a while to come up (and would need to be reset afaik). Googling M-PHY gives a lot of mentions of sleep/hibernate but I can't find a good reference document... I know DigRF3G (which is related to some extent I think) has requirements like this (at much lower rates, it doesn't need FPGA SERDES just LVDS). --------------------------------------- Posted through http://www.FPGARelated.comArticle: 157585
my understanding is that the "PLL power-up & stabilization time" is implementation dependent. The master continues in HS mode by sending SYNC symbols, then "start-of-frame". The SYNC does what its name promises, so maybe there is no need to be fast. That said, I wouldn't bet too much money on this superficial analysis. And yes, the low speed mode is probably not the only problem... --------------------------------------- Posted through http://www.FPGARelated.comArticle: 157586
Hi, I have to implement control interface in an FPGA connected to the bus with = certain width of data bus (let's assume, that it is 32 bits wide). In the c= ontrol interface I have to implement some 32-bit registers, and this is not= a problem. However additionally I have to implement some bit fields with d= ifferent widths (e.g 5 bits, 9 bits and so on). As description of the FPGA system is still evolving, to avoid continuous ma= nual adjustments, I'd like to prepare an algorithm, which could automatical= ly find the optimal distribution of those bit fields, so that they fit in t= he minimal number of registers. Of course later on there will be generated VHDL code and address table for = the software. In the first version the above is the only requirement. Later on I consider= adding certain constraints, like: "fields A and B should be if possible in= the same register", "fields C and D should NOT be in the same register" et= c. Thank you in advance, Best regards, WojtekArticle: 157587
On Monday, December 22, 2014 8:41:12 AM UTC-5, wza...@gmail.com wrote: > Hi, >=20 > I have to implement control interface in an FPGA connected to the bus wit= h certain width of data bus (let's assume, that it is 32 bits wide). In the= control interface I have to implement some 32-bit registers, and this is n= ot a problem. However additionally I have to implement some bit fields with= different widths (e.g 5 bits, 9 bits and so on). >=20 > As description of the FPGA system is still evolving, to avoid continuous = manual adjustments, I'd like to prepare an algorithm, which could automatic= ally find the optimal distribution of those bit fields, so that they fit in= the minimal number of registers. >=20 > Of course later on there will be generated VHDL code and address table fo= r the software. >=20 > In the first version the above is the only requirement. Later on I consid= er adding certain constraints, like: "fields A and B should be if possible = in the same register", "fields C and D should NOT be in the same register" = etc. >=20 > Thank you in advance, > Best regards, > Wojtek Grab the largest bit field that will fit into the available space and assig= n it to the register. Repeat this process until you're done. Example: Let's say you have five fields that are 9 bits wide; four that ar= e 5 bits wide; two that are three bits wide and one that is one bit wide. So you grab three of the 9 bit fields and assign them to one register, whic= h fills up 27 bits of register 1. You can't fit any more 9 bit fields so y= ou go to the 5 bit fields. You can fit one of those and that fills up the = first 32 bit register. Now what you have left are: Two 9 bit fields; three 5 bit fields; two 3 bi= t fields and one 1 bit field. So you grab the two 9 bit fields and then tw= o 5 bit fields for 28 bits. You're can't fit anymore 5 bit fields so you g= rab one of the 3 bit fields and then since you can't fit anymore 3 bit fiel= ds you grab the 1 bit field to fill up the remaining space in the 32 bit fi= eld. Kevin JenningsArticle: 157588
Hi, the registers are synthesized in the FPGA fabric from FFs, aren't they? If so, you could simply omit unused bits. The FFs get optimized away, they don't exist physically (this is at least done on ASICs, with a fixed default value for reading). Generally, I wouldn't micro-optimize the register space but try to arrange everything in a logical and debug-friendly order that is least likely to change in future revisions, to avoid later surprises with the SW compiler optimization. --------------------------------------- Posted through http://www.FPGARelated.comArticle: 157589
On Mon, 22 Dec 2014 05:41:10 -0800, wzab01 wrote: > Hi, > > I have to implement control interface in an FPGA connected to the bus > with certain width of data bus (let's assume, that it is 32 bits wide). > In the control interface I have to implement some 32-bit registers, and > this is not a problem. However additionally I have to implement some bit > fields with different widths (e.g 5 bits, 9 bits and so on). > > As description of the FPGA system is still evolving, to avoid continuous > manual adjustments, I'd like to prepare an algorithm, which could > automatically find the optimal distribution of those bit fields, so that > they fit in the minimal number of registers. > > Of course later on there will be generated VHDL code and address table > for the software. > > In the first version the above is the only requirement. Later on I > consider adding certain constraints, like: "fields A and B should be if > possible in the same register", "fields C and D should NOT be in the > same register" etc. > > Thank you in advance, > Best regards, > Wojtek That sounds like a recipe for the World's Most Disorganized Interface. Whoever has to write the software to interface with those registers will be Most Displeased with you if you take that approach -- the first time that you add just one bit to one of those registers and cause your nifty automatic algorithm to completely relocate everything, they'll be even _more_ displeased with you. This is something that you really need to give some thought to laying out logically. It's probably worth a bit of extra address decode now to make the product future-proof. My suggestion is to lay out the registers so they conform (as best as you can) to the following rules: 0: Document everything you do. Making this interface clear and well understood by the software team is going to be a critical part of your project success. Don't mess it up. Having your software team review a proposed interface before you commit to it is a good idea. 1: Related bits go in related registers. I.e., "motor on" and "baud rate" do not belong together. 2: Related sets of registers go together in contiguous, or mostly contiguous blocks. I.e., if you have comms stuff and motor drive stuff, don't intermix them -- keep them separate. 3: Don't be afraid of unused bits. Set your code up so that writes to unused bits are ignored, and reads always read back the same thing (0 is good). Later, if you have to add more functionality, try to make the expanded interface work "the old way" if a previously unused bit is set to 0. 4: Don't be afraid of swaths of unused registers. With a 32-bit address space, you can dedicate 1kB blocks to each function, and just have lots of unused addresses (i.e., motor control maps to 0x0000, comms to 0x0400, etc.). -- Tim Wescott Wescott Design Services http://www.wescottdesign.comArticle: 157590
W dniu poniedzia=C5=82ek, 22 grudnia 2014 19:17:21 UTC+1 u=C5=BCytkownik Ti= m Wescott napisa=C5=82: > On Mon, 22 Dec 2014 05:41:10 -0800, wzab01 wrote: >=20 > > Hi, > >=20 > > I have to implement control interface in an FPGA connected to the bus > > with certain width of data bus (let's assume, that it is 32 bits wide). > > In the control interface I have to implement some 32-bit registers, and > > this is not a problem. However additionally I have to implement some bi= t > > fields with different widths (e.g 5 bits, 9 bits and so on). > >=20 > > As description of the FPGA system is still evolving, to avoid continuou= s > > manual adjustments, I'd like to prepare an algorithm, which could > > automatically find the optimal distribution of those bit fields, so tha= t > > they fit in the minimal number of registers. > >=20 > > Of course later on there will be generated VHDL code and address table > > for the software. > >=20 > > In the first version the above is the only requirement. Later on I > > consider adding certain constraints, like: "fields A and B should be if > > possible in the same register", "fields C and D should NOT be in the > > same register" etc. > >=20 > > Thank you in advance, > > Best regards, > > Wojtek >=20 > That sounds like a recipe for the World's Most Disorganized Interface. >=20 > Whoever has to write the software to interface with those registers will= =20 > be Most Displeased with you if you take that approach -- the first time= =20 > that you add just one bit to one of those registers and cause your nifty= =20 > automatic algorithm to completely relocate everything, they'll be even=20 > _more_ displeased with you. >=20 > This is something that you really need to give some thought to laying out= =20 > logically. It's probably worth a bit of extra address decode now to make= =20 > the product future-proof. >=20 > My suggestion is to lay out the registers so they conform (as best as you= =20 > can) to the following rules: >=20 > 0: Document everything you do. Making this interface clear and well=20 > understood by the software team is going to be a critical part of your=20 > project success. Don't mess it up. Having your software team review a= =20 > proposed interface before you commit to it is a good idea. >=20 > 1: Related bits go in related registers. I.e., "motor on" and "baud rate= "=20 > do not belong together. >=20 > 2: Related sets of registers go together in contiguous, or mostly=20 > contiguous blocks. I.e., if you have comms stuff and motor drive stuff,= =20 > don't intermix them -- keep them separate. >=20 > 3: Don't be afraid of unused bits. Set your code up so that writes to=20 > unused bits are ignored, and reads always read back the same thing (0 is= =20 > good). Later, if you have to add more functionality, try to make the=20 > expanded interface work "the old way" if a previously unused bit is set t= o=20 > 0. >=20 > 4: Don't be afraid of swaths of unused registers. With a 32-bit address= =20 > space, you can dedicate 1kB blocks to each function, and just have lots o= f=20 > unused addresses (i.e., motor control maps to 0x0000, comms to 0x0400,=20 > etc.). >=20 > --=20 >=20 > Tim Wescott > Wescott Design Services > http://www.wescottdesign.com Well, that's how I have worked all the time before. This worked good until I had to extend a bitfield so that it stopped to fit in the register with other neighbouring bit fields. So now I'm investigating possibilities to optimize the control logic as muc= h as possible, with all changes hidden behind the intermediate software lay= er. The software will approach registers and bitfields via their symbolic names= obtained from the address tables (using the IPbus approach -=20 https://svnweb.cern.ch/trac/cactus/wiki/uhalQuickTutorial#CreatinganAddress= Table , however IPbus requires that you specify the register name together = with bitfield name, I'd like to fully hide it.) Of course there must be at least one ID register with known location contai= ning a unique magic number, allowing to make sure that we are talking to th= e appropriate board with appropriate firmware version...=20 May be this is just a crazy experiment... Thanks & regards, WojtekArticle: 157591
W dniu poniedzia=C5=82ek, 22 grudnia 2014 20:00:19 UTC+1 u=C5=BCytkownik wz=
a...@gmail.com napisa=C5=82:
> May be this is just a crazy experiment...
>=20
To make the whole idea even more crazy, I'could imagine, that the final pla=
cement of bit fields in registers could be optimized basing on automatic=20
analysis of control procedures implemented in software.
E.g. bit fields which are often changed together without placing "barriers"=
enforcing the particular order of operation ("hw.dispatch()" in the IPbus)=
, can be grouped in the same register, so that they are written in single o=
peration.
If they do not fit in a single register, they should be placed at consecuti=
ve locations so that they can be written by block operation and so on...
Regards,
Wojtek
Article: 157592>> May be this is just a crazy experiment... Hint: The concatenation operator ## of the C preprocessor is your best friend. It allows to generate fairly complex access macros. Completely separating register name and bitfield name is IMO not practical, as the programmer wants to combine multiple fields of the same register into one bus access, which is usually slow. The compiler cannot optimize this when hardware control registers are "volatile". I'd go out of my way to make the hardware as programming-friendly as possible. Embedded debugging is expensive, a couple of gates cost nothing (depends). For example, shadow registers or even configuration banks can make the programmer's life easier, when a single bit write triggers an atomic reconfiguration of a whole hardware block. Still about "crazy", I've seen some pretty sophisticated register management infrastructure been used in production that synthesized the register code, generated software access scripts, set up test automation GUIs, generated register list documentation etc. Maybe the ASIC folks are more paranoid about "small" mistakes, it's just a metal mask fix... --------------------------------------- Posted through http://www.FPGARelated.comArticle: 157593
mnentwig <24789@embeddedrelated> wrote: (snip) > Completely separating register name and bitfield name is IMO not practical, > as the programmer wants to combine multiple fields of the same register > into one bus access, which is usually slow. > The compiler cannot optimize this when hardware control registers are > "volatile". > I'd go out of my way to make the hardware as programming-friendly as > possible. Embedded debugging is expensive, a couple of gates cost nothing > (depends). With current addressing spaces, unless this is a very unusual system, you don't need or want that kind of optimization. For one, as you note, fields might expand. There are many systems around with unusal bit positions when something expanded and there weren't bits to expand into. As someone noted, register bits that aren't used will be optimized out at syntheis. (If you are lucky, there is a warning message.) The only cost is address space, which in most systems is cheap. > For example, shadow registers or even configuration banks can make the > programmer's life easier, when a single bit write triggers an atomic > reconfiguration of a whole hardware block. > Still about "crazy", I've seen some pretty sophisticated register > management infrastructure been used in production that synthesized the > register code, generated software access scripts, set up test automation > GUIs, generated register list documentation etc. Maybe the ASIC folks are > more paranoid about "small" mistakes, it's just a metal mask fix... But there may be some unusual systems, in which case you will have to explain in more detail. -- glenArticle: 157594
>> you don't need or want that kind of optimization I think that's not what I meant. For example, take this C example (don't read from hardware without good reason, this is only an example) volatile void* p = 0xDEADBEEF; // hardware register *p = 0x1; *p |= 0x2; *p |= 0x4; *p |= 0x8; where the above commands would result from bitfield access macros. Assuming the order does not matter, it can be simplified to a single bus access *p = 0xF; but the C compiler can't do this for me because of "volatile". That means, bit fields and registers can't be separated in the code. Change the distribution of bitfields across registers and the code will have to be rewritten. --------------------------------------- Posted through http://www.FPGARelated.comArticle: 157595
>> void* make that unsigned short * ... --------------------------------------- Posted through http://www.FPGARelated.comArticle: 157596
W dniu wtorek, 23 grudnia 2014 00:41:28 UTC+1 u=C5=BCytkownik mnentwig napi= sa=C5=82: > >> you don't need or want that kind of optimization >=20 > I think that's not what I meant. > For example, take this C example (don't read from hardware without good > reason, this is only an example) > volatile void* p =3D 0xDEADBEEF; // hardware register > *p =3D 0x1; > *p |=3D 0x2; > *p |=3D 0x4; > *p |=3D 0x8; >=20 > where the above commands would result from bitfield access macros. > Assuming the order does not matter, it can be simplified to a single bus > access > *p =3D 0xF; >=20 > but the C compiler can't do this for me because of "volatile". > That means, bit fields and registers can't be separated in the code. Chan= ge > the distribution of bitfields across registers and the code will have to = be > rewritten. =20 > =09 > --------------------------------------- =09 > Posted through http://www.FPGARelated.com That's exactly what I meant writing "the final placement of bit fields in r= egisters could be optimized basing on automatic analysis of control procedu= res implemented in software". BTW the IPbus implementation coalesces such operations, transforming them i= nto a single access on the fly (all operations issued between calls to disp= atch() may be treated that way). --=20 Regards, WojtekArticle: 157597
>BTW the IPbus implementation coalesces such operations, transforming them into a single access on the fly (all operations issued between calls to disp= >atch() may be treated that way). Thanks, I'll have a look at the programming API. I've been thinking myself about abstracting register access, collect all bits in a temporary stack variable and use some finalizer (probably similar to your "dispatch") to execute the bus access. Manually collecting all bit fields per register as in my code is boneheaded, it just happens to work in real life. Debugging would be my main concern, but then the manual version (as in my example) isn't exactly maintenance-friendly either. I could imagine that with an IP-based connection there is more incentive to optimize the bus access. With everything on one chip, it's a concern but I wouldn't expect it at the top of my priority list. By the way, the packing problem itself could actually be some NP-complete integer programming thing (just guessing): http://en.wikipedia.org/wiki/Set_packing But simple heuristics (earlier posts) would surely work well enough. --------------------------------------- Posted through http://www.FPGARelated.comArticle: 157598
Den mandag den 22. december 2014 19.17.21 UTC+1 skrev Tim Wescott: > On Mon, 22 Dec 2014 05:41:10 -0800, wzab01 wrote: > > > Hi, > > > > I have to implement control interface in an FPGA connected to the bus > > with certain width of data bus (let's assume, that it is 32 bits wide). > > In the control interface I have to implement some 32-bit registers, and > > this is not a problem. However additionally I have to implement some bit > > fields with different widths (e.g 5 bits, 9 bits and so on). > > > > As description of the FPGA system is still evolving, to avoid continuous > > manual adjustments, I'd like to prepare an algorithm, which could > > automatically find the optimal distribution of those bit fields, so that > > they fit in the minimal number of registers. > > > > Of course later on there will be generated VHDL code and address table > > for the software. > > > > In the first version the above is the only requirement. Later on I > > consider adding certain constraints, like: "fields A and B should be if > > possible in the same register", "fields C and D should NOT be in the > > same register" etc. > > > > Thank you in advance, > > Best regards, > > Wojtek > > That sounds like a recipe for the World's Most Disorganized Interface. > > Whoever has to write the software to interface with those registers will > be Most Displeased with you if you take that approach -- the first time > that you add just one bit to one of those registers and cause your nifty > automatic algorithm to completely relocate everything, they'll be even > _more_ displeased with you. > > This is something that you really need to give some thought to laying out > logically. It's probably worth a bit of extra address decode now to make > the product future-proof. > > My suggestion is to lay out the registers so they conform (as best as you > can) to the following rules: > > 0: Document everything you do. Making this interface clear and well > understood by the software team is going to be a critical part of your > project success. Don't mess it up. Having your software team review a > proposed interface before you commit to it is a good idea. > > 1: Related bits go in related registers. I.e., "motor on" and "baud rate" > do not belong together. > > 2: Related sets of registers go together in contiguous, or mostly > contiguous blocks. I.e., if you have comms stuff and motor drive stuff, > don't intermix them -- keep them separate. > > 3: Don't be afraid of unused bits. Set your code up so that writes to > unused bits are ignored, and reads always read back the same thing (0 is > good). Later, if you have to add more functionality, try to make the > expanded interface work "the old way" if a previously unused bit is set to > 0. > > 4: Don't be afraid of swaths of unused registers. With a 32-bit address > space, you can dedicate 1kB blocks to each function, and just have lots of > unused addresses (i.e., motor control maps to 0x0000, comms to 0x0400, > etc.). > that can also makes the decoding a bit easier I'd add that keeping something like a number on a four bit boundary makes it a bit more human readable and having bitset/bitclear for certain registers can make the code smaller and life a bit easier -LasseArticle: 157599
On Wednesday, 26 November 2014 20:01:18 UTC+1, Theo Markettos wrote: > Anyone know if there's a standard(ish) for simple mezzanine cards for FPGA > boards? > > I know about things like FMC and HSMC which are very 'high end' - multi > gigabit transceivers, expensive connectors. There's also Arduino, which is > simple and low pin count, but everything is designed to talk to a dumb slow > Atmega (which usually means putting another Atmega on the mezzanine card and > talking via SPI). Or there's Raspberry Pi, but again it's assumes you have > slow I/O and things like Ethernet and USB already exist on the CPU board. > > Is there anything between the two? Something like an Arduino-scale system > but with a $10 FPGA in mind rather than an 8 bit micro or a $1000 FPGA. For > instance, an 100M Ethernet PHY which is just the phy rather than a > memory-mapped MAC, and so just presents an RMII or SMII interface. Or a > USB2 ULPI PHY. Having a microcontroller on the board is OK (USB offload is > a useful task), just drinking it through an SPI straw is not. > > I found: > http://www.wvshare.com/column/Accessory_Boards.htm?1 > which seems to be cheap boards all over ebay that are rather Arduino-like > while intended for FPGAs, but there doesn't seem to be much of a community > around them (in other words, they might disappear tomorrow). > > Any other ideas? > > Thanks > Theo yes and IDEA is born, will be public soon - [prelim spec deleted here, sorry] Antti wishes merry Christmas
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