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
Hi Andy, On 20/09/2013 23:51, jonesandy@comcast.net wrote: > If you only have one clock frequency, here is a decent starting > point: I'm assuming that a system clock and a divided-by-two clock with an internal PLL are still synchronous under all conditions. > Synplify has an option to set a default clock frequency and another > to apply the clock period to all unconstrained IO. > > If you have any IO that need tighter constraints than one clock > period, you will need to set those up in the constraints manager. So far I'm using SDC files to setup constraints and let Synplify check the constraint file. But I'll explore the constraints manager... > Microsemi also has a good online tutorial for setting up constraints > for source-synchronous interfaces using virtual clocks. I'm actually looking up the documentation for the 'SCOPE' tool, even though I think I will convert it to SDC once everything is ruled out. I prefer to have physical constraints and timing constraints separate. > I prefer to set timing constraints in synthesis so that they are > available for both Synplify and Designer. I do not use the Libero > front end, only Synplify and Designer. I use ModelSim, Synplify and Designer separately. I find the Libero front-end is most of the time in my way... I believe that setting the time constraints during synthesis allows you to have more control on the overall margin that can be taken away during P&R. > If you can avoid them, do not use multi-cycle or false path > constraints. They are very difficult to verify without much more > expensive tools. It is way too easy to relax the timing on unintended > paths with these constraints, and unless you hit just the right > conditions in a post-P&R simulation, you'll never know it (until > wierd stuff starts happening in the lab or in the field). I do not particularly like false paths either, especially because it would mean extra efforts to exclude them from verification as well...Article: 155826
On Saturday, September 21, 2013 1:59:18 AM UTC+12, dit...@gmail.com wrote: >=20 > I will need to reproduce all logical levels into and out of the chip with= timing faithful to the original chip (or as close as I can get it, divide = is going to be an issue). A lot of the circuits on the board are old 54-ser= ies discrete logic, so those all get sucked in too, so we wind up emulating= the tri-state internal to the FPGA. Outside, we have lots of level convert= ers and discrete control to faithfully replicate the 5V tri-state. >=20 If you are doing the CPU plus external logic, then you are even safer, as y= our end result looks nothing like the original, nor can it drop into an or= iginal socket. What Clock Speed, Code and Data memory do you need to have, to match the or= iginal ?Article: 155827
ditiris@gmail.com wrote: > Wow, lots of activity since I last checked. To answer some questions: > > This is for business, not an educational exercise. > > The chip is in the TI 9900 family (weird architecture). > . . . . > However, we're still going to consult with a lawyer just to be sure. You might try to contact TI directly. I have found that the silicon companies can be quite co-operative given a some good reasons why you need to do this. Often helping customers even when they are not going to gain in future consideration. Hiding from them until they find you can be messy all round. A gentle engineering approach perhaps passing the material you intend to disclose to them past a lawyer to understand pitfalls will often solve problems like this. Walter..Article: 155828
On 26/09/13 20:12, Walter Banks wrote: > > > ditiris@gmail.com wrote: > >> Wow, lots of activity since I last checked. To answer some questions: >> >> This is for business, not an educational exercise. >> >> The chip is in the TI 9900 family (weird architecture). >> . . . . > >> However, we're still going to consult with a lawyer just to be sure. > > You might try to contact TI directly. I have found that the silicon > companies can be quite co-operative given a some good reasons > why you need to do this. Often helping customers even when they > are not going to gain in future consideration. Hiding from them > until they find you can be messy all round. > > A gentle engineering approach perhaps passing the material you > intend to disclose to them past a lawyer to understand pitfalls > will often solve problems like this. > > Walter.. > Almost certainly, TI will be unhelpful here. To give a proper answer, they would have to involve their own lawyers to figure out what to say, and that is simply too expensive for a case like this. So they will either say nothing at all, or say "No". If you are really lucky, you might get something that implies that they don't care, without actually saying so directly. I think, however, that /if/ things get ugly in the future and TI tries to sue you, then you could point to such an conversation with TI as evidence that you did your best to do the right thing.Article: 155829
David Brown <david@westcontrol.removethisbit.com> wrote: (snip) > Almost certainly, TI will be unhelpful here. To give a proper answer, > they would have to involve their own lawyers to figure out what to say, > and that is simply too expensive for a case like this. So they will > either say nothing at all, or say "No". If you are really lucky, you > might get something that implies that they don't care, without actually > saying so directly. Note that not all companies are like that. Sun released verilog code for 64 bit SPARC. You can legally build and sell one. It seems to be now on the Oracle web site. > I think, however, that /if/ things get ugly in the future and TI tries > to sue you, then you could point to such an conversation with TI as > evidence that you did your best to do the right thing. -- glenArticle: 155830
On 27/09/13 13:51, glen herrmannsfeldt wrote: > David Brown <david@westcontrol.removethisbit.com> wrote: > > (snip) > >> Almost certainly, TI will be unhelpful here. To give a proper answer, >> they would have to involve their own lawyers to figure out what to say, >> and that is simply too expensive for a case like this. So they will >> either say nothing at all, or say "No". If you are really lucky, you >> might get something that implies that they don't care, without actually >> saying so directly. > > Note that not all companies are like that. Sun released verilog > code for 64 bit SPARC. You can legally build and sell one. > It seems to be now on the Oracle web site. I don't mean to say that TI are particularly secretive or awkward about these things. It's just a matter of economics - a big company is unlikely to give you permission to copy their IP without first passing it through the lawyers. When it is an active decision from the company - such as with Sun, where they felt it would be a good idea if more people used SPARCs even if they were not made by Sun - it is worth calling the lawyers. When it is a single person asking, with no return for TI, then doing things legally correctly means quite a lot of time and money for TI. While TI staff have always been nice and helpful in my experience, there is a limit to how much you can expect them to do to be "nice". > >> I think, however, that /if/ things get ugly in the future and TI tries >> to sue you, then you could point to such an conversation with TI as >> evidence that you did your best to do the right thing. > > -- glen >Article: 155831
On Fri, 20 Sep 2013 12:08:23 -0500, Tim Wescott wrote: > On Fri, 20 Sep 2013 06:59:18 -0700, ditiris wrote: > >> Wow, lots of activity since I last checked. To answer some questions: >> >> This is for business, not an educational exercise. >> >> The chip is in the TI 9900 family (weird architecture). >> >> I will need to reproduce all logical levels into and out of the chip >> with timing faithful to the original chip (or as close as I can get it, >> divide is going to be an issue). A lot of the circuits on the board are >> old 54-series discrete logic, so those all get sucked in too, so we >> wind up emulating the tri-state internal to the FPGA. Outside, we have >> lots of level converters and discrete control to faithfully replicate >> the 5V tri-state. >> >> The application is real-time, so I think that rules out software >> emulation. I explored that path a bit, but after reading up on SNES >> emulators (1991 3.58MHz 16-bit CPU) and finding that most are heavily >> optimized and largely written in assembly, I figured HDL was a better >> cost-value-risk proposal. When I got to the part how most software >> emulators only work most of the time and they actually need a 3GHz >> multi-core CPU to accurately model the SNES hardware delays in all >> cases, I was really convinced HDL was the way to go... >> >> Software emulators are apparently fine legally, and I think that's a >> close corollary to what we'll be doing. Given that Tekmos has a >> business at all, we should really be fine. >> >> However, we're still going to consult with a lawyer just to be sure. > > Legal problems aside, if there's an emulator out there that's 100% > accurate but for timing, and if you can do it this way, I'd run it fast > enough so that the slowest instruction happens on time, then slow all > the other ones down to match. > > That gets difficult if some execution times are data-dependent. > > As far as actual legal problems -- I think you're OK, but talking to a > lawyer is a Good Idea. > > First TI would have to care. Then they'd have to dare. Your biggest > problem would be some TI lawyer trying to justify his pay by finding an > encroachment, and you getting squished long before you can win just > because they're so much bigger than you. I agree with Tim on using an emulator if you can. I do not see why you need to get down to the gate level. I have never done any work with this CPU but a quick search brings up many emulators for the TI-99 game system that, from what I read, used the TMS9900. Pull the core cpu emulator code out of one of these and put it in a fast micro, possibly one that will run out of SRAM. You can tie the micro's ISR into the emulator so you get good interrupt timing. You will still probably have to hang some interface logic around the micro. The nice thing about using the emulator is you can get it running on a PC or even a target micro development board, and get the basic bugs worked out. The HDL approach would be a very interesting project and a lot of fun but I think you are under estimating the level of effort to take something from OpenCores and get it to production level. -- Chisolm Republic of TexasArticle: 155832
On Fri, 27 Sep 2013 15:32:31 +0200, David Brown wrote: > On 27/09/13 13:51, glen herrmannsfeldt wrote: >> David Brown <david@westcontrol.removethisbit.com> wrote: >> >> (snip) >> >>> Almost certainly, TI will be unhelpful here. To give a proper answer, >>> they would have to involve their own lawyers to figure out what to >>> say, >>> and that is simply too expensive for a case like this. So they will >>> either say nothing at all, or say "No". If you are really lucky, you >>> might get something that implies that they don't care, without >>> actually saying so directly. >> >> Note that not all companies are like that. Sun released verilog code >> for 64 bit SPARC. You can legally build and sell one. >> It seems to be now on the Oracle web site. > > I don't mean to say that TI are particularly secretive or awkward about > these things. It's just a matter of economics - a big company is > unlikely to give you permission to copy their IP without first passing > it through the lawyers. When it is an active decision from the company > - such as with Sun, where they felt it would be a good idea if more > people used SPARCs even if they were not made by Sun - it is worth > calling the lawyers. When it is a single person asking, with no return > for TI, then doing things legally correctly means quite a lot of time > and money for TI. While TI staff have always been nice and helpful in > my experience, there is a limit to how much you can expect them to do to > be "nice". TI recently released a lot of code for a slightly newer CPU, I think it would be worth talking to them about the 9900.Article: 155833
Hello All, It has been many years since I used the Synopsys Design Constraint (SDC) la= nguage to apply timing constraints to a logic design. Right now I am worki= ng on a preexisting Altera Cyclone 4 FPGA design and I believe that the I/O= constraints are not complete. Unfortunately, my first attempts to constra= in I/O on the part result in Altera timing reports that are incomprehensibl= e to me. Some of the clocking schemes in this part are very complicated. I = think I need to go back to school and really understand SDC. Can anyone recommend a good "Theory and Practice" document for SDC timing c= onstraints? Thank you for any advice. Pete DudleyArticle: 155834
I'm still looking for this option. I attended the intro Vivado training yesterday. The instructor told me there was an option under the Synthesis Settings menu but I cannot find it. I will submit a feature request on the Xilinx WebCase system.Article: 155835
Those pcie compile scripts are a little loose but not too complicated. Look inside to see what it is doing and in what directory it expects that file. Most important, don't give up. PeteArticle: 155836
Please listen to Kevin and all the others who recommend good version contro=
l practices with FPGA design. Most of the best version control tools, Subve=
rsion, GIT, etc, are free and open now. Check in early and check in often.=
Don't worry about disk space. Disk drive space is essentially free now.
The original question of this thread was about how to get a timestamp or si=
milar unique identifier into each and every compile. A precompile tcl scri=
pt sounds like a good approach. It could spit out a little HDL module with=
the desired info so that it can be read from the fpga by a cpu.
My old company (wisely) tried to make each fpga bitfile uniquely identifiab=
le so that the control software could verify that it is running the right f=
pga at boot time. It was very difficult to remember to manually edit a bit=
of HDL just to insert some updated version code.
Software guys often insert the subversion revision code into their compiled=
software builds. That is ideal but doesn't work with FPGA's because you d=
on't know if your code works (meets timing, etc) and is releaseable until a=
fter you compile.
Pete
Article: 155837Am Freitag, 27. September 2013 15:32:31 UTC+2 schrieb David Brown: [...] > When it is a single person asking, with no return > for TI, then doing things legally correctly means quite a lot of time > and money for TI. While TI staff have always been nice and helpful in > my experience, there is a limit to how much you can expect them to do to > be "nice". In the case of the MSP430 microcontroller series, TI links to Opencore's openmsp430 implementation from their Open Source Projects wiki page (which at least seems to be a semi-official resource): http://processors.wiki.ti.com/index.php/Open_Source_Projects_-_MSP430#OpenMSP430 While the openmsp430 is, of course, an open source project, it has been successfully used in various commercial projects IIRC (it's also been implemented in an ASIC, so that doesn't sound quite like a hobby project anymore). -- MichaelArticle: 155838
I've recently discovered that Lattice MachXO2 is quite a nice family of
low-end FPGAs. I like especially the built-in oscillator (but +/- 5.5% is
not good enough for async serial- +/- 1% would be better) and the built-in
1.2V core linear regulator which allows operation of the chip with 3.3V only
(next generation they should work on an integrated switching regulator). I
can also wish for more analog peripherals (ADC, comparators, anything I can
find on PIC microcontrollers...).
Anyway, they certainly make the system cost lower when compared with Altera
or Xilinx.
Also nice is the MachXO2 breakout board. The feature I like is that the
built-in USB programmer chip from FTDI is a dual-function device. It has
both the JTAG programmer, but also has a USB-to-RS-232 converter which shows
up as a separate USB device in Windows. I can have a console serial
connection with PuTTY and at the same time have the Lattice Programmer.
Very nice.
It's been an interesting experience using Lattice Diamond. I think just a
few minor tweeks would make it a lot more usable:
Dump the whole multiple-implementation within one design concept. Most
projects are only going to have single implementaton, and I think it's
reasonable to create a new project for a new implementaion (the new project
could use the same source files an existing one to get the same effect as
multiple implementations). Anyway, this would reduce clutter.
I got confused when trying to change the PULLMODE using the spreadsheet
view. The problem is that spreadsheet view does not consider the .lpf file
as changed until you actually move off of the cell you just modified. I
think this is a straight bug.
There is a run-manager which lets you select an implementation and has its
own button for "Run". When you run this way, the Export Files (like JEDEC
or bitstream files) process is not automatically run.
But then there is the "Process" pulldown on the main menu bar. This also
has "Run" and "Run All", but they are disabled unless you select something
from the Process pane. "Run All" does actually run the Export Files
process.
Anyway, it's pointless that there are multiple ways to run. Again, dump the
multi-implementation stuff and have a single run-all button.
I tried the Reveal logic analyzer, but no luck first time. After insertion
I can no longer place and route the design with the only error shown as
"Done: error 1". Even after disabling Reveal (also not obvious how this is
done), the error remains.
--
/* jhallen@world.std.com AB1GO */ /* Joseph H. Allen */
int a[1817];main(z,p,q,r){for(p=80;q+p-80;p-=2*a[p])for(z=9;z--;)q=3&(r=time(0)
+r*57)/7,q=q?q-1?q-2?1-p%79?-1:0:p%79-77?1:0:p<1659?79:0:p>158?-79:0,q?!a[p+q*2
]?a[p+=a[p+=q]=q]=q:0:0;for(;q++-1817;)printf(q%79?"%c":"%c\n"," #"[!a[q-1]]);}
Article: 155839On 29/09/2013 06:24, Joseph H Allen wrote: > I've recently discovered that Lattice MachXO2 is quite a nice family of > low-end FPGAs. I like especially the built-in oscillator (but +/- 5.5% is > not good enough for async serial- +/- 1% would be better) and the built-in > 1.2V core linear regulator which allows operation of the chip with 3.3V only > (next generation they should work on an integrated switching regulator). I > can also wish for more analog peripherals (ADC, comparators, anything I can > find on PIC microcontrollers...). > > Anyway, they certainly make the system cost lower when compared with Altera > or Xilinx. > > Also nice is the MachXO2 breakout board. The feature I like is that the > built-in USB programmer chip from FTDI is a dual-function device. It has > both the JTAG programmer, but also has a USB-to-RS-232 converter which shows > up as a separate USB device in Windows. I can have a console serial > connection with PuTTY and at the same time have the Lattice Programmer. > Very nice. > > It's been an interesting experience using Lattice Diamond. I think just a > few minor tweeks would make it a lot more usable: > > Dump the whole multiple-implementation within one design concept. Most > projects are only going to have single implementaton, and I think it's > reasonable to create a new project for a new implementaion (the new project > could use the same source files an existing one to get the same effect as > multiple implementations). Anyway, this would reduce clutter. > > I got confused when trying to change the PULLMODE using the spreadsheet > view. The problem is that spreadsheet view does not consider the .lpf file > as changed until you actually move off of the cell you just modified. I > think this is a straight bug. > > There is a run-manager which lets you select an implementation and has its > own button for "Run". When you run this way, the Export Files (like JEDEC > or bitstream files) process is not automatically run. > > But then there is the "Process" pulldown on the main menu bar. This also > has "Run" and "Run All", but they are disabled unless you select something > from the Process pane. "Run All" does actually run the Export Files > process. > > Anyway, it's pointless that there are multiple ways to run. Again, dump the > multi-implementation stuff and have a single run-all button. > > I tried the Reveal logic analyzer, but no luck first time. After insertion > I can no longer place and route the design with the only error shown as > "Done: error 1". Even after disabling Reveal (also not obvious how this is > done), the error remains. > While Diamond is not perfect you should remember that it is intended to support the whole range of Lattice FPGAs which includes devices much bigger devices than the XO2. The multiple ways of running get useful when it takes a significant amount of time to complete the whole process and you just want to run a bit of it. I haven't had much joy with Reveal. Don't hold your breath for ADCs - the XO3 (just announced and not available for some time) doesn't have any. Michael KellettArticle: 155840
peter dudley <padudle@gmail.com> writes: > The original question of this thread was about how to get a timestamp > or similar unique identifier into each and every compile. A precompile > tcl script sounds like a good approach. It could spit out a little HDL > module with the desired info so that it can be read from the fpga by a > cpu. Or you can simply pass a generic/parameter which contains the SHA-1 or whatever in your synthesis script. Another common approach is go generate a MIF file or similar RAM contents file containing the SHA-1/dirty/passed. Typically this RAM will act like a ROM (e.g. the write signal is never asserted within the FPGA logic) > My old company (wisely) tried to make each fpga bitfile uniquely > identifiable so that the control software could verify that it is > running the right fpga at boot time. It was very difficult to remember > to manually edit a bit of HDL just to insert some updated version > code. It's also quite common to use a script to extract the SHA-1 etc. and insert it automatically. > Software guys often insert the subversion revision code into their > compiled software builds. That is ideal but doesn't work with FPGA's > because you don't know if your code works (meets timing, etc) and is > releaseable until after you compile. You can still generate the SHA-1 etc. and keep track if that particular release meet timing etc. elsewhere. Or if you use the mentioned MIF approach described above you can use a vendor supplied tool to quickly update the content of the RAM after build to include the timing information. //Petter -- .sig removed by request.Article: 155841
On 9/29/2013 1:24 AM, Joseph H Allen wrote: > I've recently discovered that Lattice MachXO2 is quite a nice family of > low-end FPGAs. I like especially the built-in oscillator (but +/- 5.5% is > not good enough for async serial- +/- 1% would be better) ... > I've used a much worse built-in oscillator (from Spartan 6) for async serial communication. It turns out that most of the tolerance is due to process, which won't change for any given device. So in my application I made an auto-baud detect FSM and required the host side to send a capital "U" character with minimum 10 ms gap before and after it. This sets (or changes) the baud rate simply due to the sequence of 1's and 0's. I've found that even after significant warm up the link still operates within tolerance. Requiring the protocol to occasionally update the baud rate would allow for changes in temperature if necessary. -- GaborArticle: 155842
I - not being a lawyer as well - think that this simple CPU would not cause legal problems. CPUs that use microcode probably would - if you don't create the microcode part on your own but copy it from, say, a BIOS which dynamically updates the genuine chip. Even conservative copyright fighters should agree that it is kind of strange to copyright simple commands like branch if not zero, add a<-a+b and so on. Complex math or cipher algorithms in modern CPUs might be different. Asking a lawyer would probably help only the lawyer - I cannot imagine many of them have worked intensively on this issue, so they have no experience and need to invest many hours - I don't know your local rates, but here 200 EUR/h for a specialist would be a bargain. So the only advantage is probably that he is used to the topic when you call him to defend you in a lawsuit :> Am 18.09.2013 06:30, schrieb ditiris@gmail.com: > This might not be the best group to ask, but I figured I would start here. I need to duplicate a 35-year-old CPU. Are there legal ramifications doing this? > > For instance on OpenCores they have a partially-compliant C54x DSP core. I assume the partial compliance is in part not to run into licensing issues and have TI sue them. However, I need to duplicate the CPU's instruction set and associated cycle count exactly, so I'm pretty much going to copy the CPU using the existing documentation. > > Thanks in advance for the help. >Article: 155843
In article <PKqdnUrbYqd0Q9rPnZ2dnUVZ7sydnZ2d@bt.com>,
MK <mk@nospam.co.uk> wrote:
>While Diamond is not perfect you should remember that it is intended to
>support the whole range of Lattice FPGAs which includes devices much
>bigger devices than the XO2.
>The multiple ways of running get useful when it takes a significant
>amount of time to complete the whole process and you just want to run a
>bit of it.
I'm spoiled by Quartus-II: it has "revisions", but the feature is completely
hidden unless you select Project=>Revisions. I use a source code control
system, so having this feature in the FPGA is less necessary for me.
>I haven't had much joy with Reveal.
I'll keep trying it :-)
>Don't hold your breath for ADCs - the
>XO3 (just announced and not available for some time) doesn't have any.
The field is wide open for these features. Logic is logic, so this could be
something new to compete over.
--
/* jhallen@world.std.com AB1GO */ /* Joseph H. Allen */
int a[1817];main(z,p,q,r){for(p=80;q+p-80;p-=2*a[p])for(z=9;z--;)q=3&(r=time(0)
+r*57)/7,q=q?q-1?q-2?1-p%79?-1:0:p%79-77?1:0:p<1659?79:0:p>158?-79:0,q?!a[p+q*2
]?a[p+=a[p+=q]=q]=q:0:0;for(;q++-1817;)printf(q%79?"%c":"%c\n"," #"[!a[q-1]]);}
Article: 155844
In article <l29lbh$6qh$1@dont-email.me>, Gabor <gabor@szakacs.org> wrote:
>On 9/29/2013 1:24 AM, Joseph H Allen wrote:
>> I've recently discovered that Lattice MachXO2 is quite a nice family of
>> low-end FPGAs. I like especially the built-in oscillator (but +/- 5.5% is
>> not good enough for async serial- +/- 1% would be better) ...
>>
>
>I've used a much worse built-in oscillator (from Spartan 6) for async
>serial communication. It turns out that most of the tolerance is due
>to process, which won't change for any given device. So in my
>application I made an auto-baud detect FSM and required the host
>side to send a capital "U" character with minimum 10 ms gap before
>and after it. This sets (or changes) the baud rate simply due to the
>sequence of 1's and 0's. I've found that even after significant warm
>up the link still operates within tolerance. Requiring the protocol
>to occasionally update the baud rate would allow for changes in
>temperature if necessary.
Are you using CFGMCLK? Interesting.. +/- 55%! This seems to be available
starting Virtex-4.
Well I guess you get auto baud rate detection as a side benefit.
--
/* jhallen@world.std.com AB1GO */ /* Joseph H. Allen */
int a[1817];main(z,p,q,r){for(p=80;q+p-80;p-=2*a[p])for(z=9;z--;)q=3&(r=time(0)
+r*57)/7,q=q?q-1?q-2?1-p%79?-1:0:p%79-77?1:0:p<1659?79:0:p>158?-79:0,q?!a[p+q*2
]?a[p+=a[p+=q]=q]=q:0:0;for(;q++-1817;)printf(q%79?"%c":"%c\n"," #"[!a[q-1]]);}
Article: 155845On Monday, September 30, 2013 12:15:08 PM UTC+12, Joseph H Allen wrote: > > >Don't hold your breath for ADCs - the > >XO3 (just announced and not available for some time) doesn't have any. > > The field is wide open for these features. Logic is logic, so this could be > something new to compete over. ADCs are not quite Logic. Harder to get right, and more costly to test. However what they could include, which is just logic, is support for the isolated/separate Sigma-Delta ADC front ends from ADi / Maxim etc.Article: 155846
Joseph H Allen wrote: > In article <l29lbh$6qh$1@dont-email.me>, Gabor <gabor@szakacs.org> wrote: >> On 9/29/2013 1:24 AM, Joseph H Allen wrote: >>> I've recently discovered that Lattice MachXO2 is quite a nice family of >>> low-end FPGAs. I like especially the built-in oscillator (but +/- 5.5% is >>> not good enough for async serial- +/- 1% would be better) ... >>> >> I've used a much worse built-in oscillator (from Spartan 6) for async >> serial communication. It turns out that most of the tolerance is due >> to process, which won't change for any given device. So in my >> application I made an auto-baud detect FSM and required the host >> side to send a capital "U" character with minimum 10 ms gap before >> and after it. This sets (or changes) the baud rate simply due to the >> sequence of 1's and 0's. I've found that even after significant warm >> up the link still operates within tolerance. Requiring the protocol >> to occasionally update the baud rate would allow for changes in >> temperature if necessary. > > Are you using CFGMCLK? Interesting.. +/- 55%! This seems to be available > starting Virtex-4. Exactly. I was pleasantly surprised at the low temperature drift in the Spartan 6, especially given the huge range over PVT. As I said it appears that Process gives the lion's share of the 55%. > > Well I guess you get auto baud rate detection as a side benefit. > In my case this came by necessity. I was using an external SiLabs clock generator that needed to be programmed via I2C in order to get any clocks to the FPGA. Once that is up and running, I've got some very precise clocks to use. Unfortunately the settings for the SiLabs chip get uploaded from a COM port, so I needed to have some way to bootstrap the system. The internal clock, bad as it is, saved me the expense of an additional clock oscillator. It also gives me a way to operate I2C, even when I already have the settings uploaded. The SiLabs chip stops outputting clocks while it is re-preogrammed. Of course an I2C master does not need a precise clock. -- GaborArticle: 155847
On 9/30/2013 10:36 AM, GaborSzakacs wrote: > > In my case this came by necessity. I was using an external SiLabs > clock generator that needed to be programmed via I2C in order to get > any clocks to the FPGA. Once that is up and running, I've got some > very precise clocks to use. Unfortunately the settings for the > SiLabs chip get uploaded from a COM port, so I needed to have some > way to bootstrap the system. The internal clock, bad as it is, saved me > the expense of an additional clock oscillator. It also gives me > a way to operate I2C, even when I already have the settings uploaded. > The SiLabs chip stops outputting clocks while it is re-preogrammed. > Of course an I2C master does not need a precise clock. Couldn't you have just used some default settings for the clock chip which would give you a workable baud rate, then update the settings from the com port? -- RickArticle: 155848
In article <l2afqc$679$1@pcls7.std.com>,
Joseph H Allen <jhallen@TheWorld.com> wrote:
>In article <PKqdnUrbYqd0Q9rPnZ2dnUVZ7sydnZ2d@bt.com>,
>MK <mk@nospam.co.uk> wrote:
>>I haven't had much joy with Reveal.
>I'll keep trying it :-)
I did get it to work. One gotcha is that your clock (the sample clock for
reveal) must be faster than the JTAG clock. I'm not really sure what
frequency the JTAG clock is, but faster than 7 MHz but slower than 66.5 MHz.
Second is the error return mystery from par. Par completed, but GUI said it
had an error. Even with the error return the GUI proceded with bitgen if I
asked it to. The GUI is definitely rough.. I also experienced some more
glitches with the spreadsheet view.
--
/* jhallen@world.std.com AB1GO */ /* Joseph H. Allen */
int a[1817];main(z,p,q,r){for(p=80;q+p-80;p-=2*a[p])for(z=9;z--;)q=3&(r=time(0)
+r*57)/7,q=q?q-1?q-2?1-p%79?-1:0:p%79-77?1:0:p<1659?79:0:p>158?-79:0,q?!a[p+q*2
]?a[p+=a[p+=q]=q]=q:0:0;for(;q++-1817;)printf(q%79?"%c":"%c\n"," #"[!a[q-1]]);}
Article: 155849rickman wrote: > On 9/30/2013 10:36 AM, GaborSzakacs wrote: >> >> In my case this came by necessity. I was using an external SiLabs >> clock generator that needed to be programmed via I2C in order to get >> any clocks to the FPGA. Once that is up and running, I've got some >> very precise clocks to use. Unfortunately the settings for the >> SiLabs chip get uploaded from a COM port, so I needed to have some >> way to bootstrap the system. The internal clock, bad as it is, saved me >> the expense of an additional clock oscillator. It also gives me >> a way to operate I2C, even when I already have the settings uploaded. >> The SiLabs chip stops outputting clocks while it is re-preogrammed. >> Of course an I2C master does not need a precise clock. > > Couldn't you have just used some default settings for the clock chip > which would give you a workable baud rate, then update the settings from > the com port? > I could, but the settings for this particular chip would eat up a block RAM if I stored them internal to the FPGA. So I placed them in the attached SPI flash along with other general device settings. I could also pre-program the SPI flash but it's generally easier for manufactufing to upload everything starting from blank parts. Once the unit has settings uploaded, it can come up running on the next power cycle. I still keep the communication port working from the internal oscillator because it's easier than switching clocks, though. I do have code that calibrates the baud divisor when the external clocks are running. Still it wasn't too much of a hardship to require the auto-baud startup in the protocol from the PC host. At one time I was generating MCS files for the device that contained both the FPGA bitstream and the settings, but it turns out that Impact is very slow and stupid about programming the SPI flash when there are big gaps between individual files, so the self-programming with upload from a 115,200 baud COM port was actually faster. Now we only use JTAG for the initial FPGA bitstream, and all subsequent updates are done via the COM port, including FPGA bitstream updates. -- Gabor
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