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 13 Nov 2013 09:53:53 +0000 (GMT) Theo Markettos <theom+news@chiark.greenend.org.uk> wrote: > Rob Gaddi <rgaddi@technologyhighland.invalid> wrote: > > Well, now I know why I'm getting old junk transactions stuck in my > > clock crossing bridge after resetting one side. Does anyone have a > > reason why one might want to reset only one side or the other of the > > FIFO, or is this (undocumented, of course) behavior just silly? > > I'm not completely clear on why that happens. You need two inputs because > each reset needs to be in the right clock domain, otherwise Excitement (TM) > happens if you try and clock domain cross with the resets. Perhaps the > model is that the resets only reset the parts in the domain that belongs to > it, and propagating the resets is your problem. > > How are you generating the clocks for the two parts? I think the standard > Qsys clock input block will also synchronise a reset to a given clock > - perhaps you need one of those? > > Theo And yet the entire point of the core is clock domain crossing, so they should have had the resets cross and resynchronize as well. A halfway-reset FIFO is a broken FIFO. The clocks/resets for the two parts are entirely independent. One is the 125 MHz clock that comes out of the PCIe core (which at least on Arria II can't be PLL'd like a real clock). The other is my own free-running 125 MHz clock. My system is a multi-mastered bus in which PCIe is one of the possible masters. The main logic has to all run from the free-running clock since PCIe availability isn't required for operation of the rest of the world. The solution I used was to tie both resets to both sides of the clock crossing bridge. This forces Qsys to generate reset adapters on both sides that OR the two resets and synchronize the deasserting edge to the respective clock. But if you just rely on Qsys to automatically add your clock crossings, it won't do that. Hence, if you do have two independent reset domains, it'll wreck the FIFO. -- Rob Gaddi, Highland Technology -- www.highlandtechnology.com Email address domain is currently out of order. See above to fix.Article: 156051
On 11/11/13 23:22, Mike Ng wrote: > On Monday, November 11, 2013 4:28:24 AM UTC-5, Tom Gardner wrote: >> Out of curiosity, how long ago did you buy them and how long did >> they take to materialise? Currently Avnet are showing no stock >> and 5 weeks lead time. >> >> Worryingly, it has been "5 weeks" for the past 3 weeks - so I'm >> concerned that Avnet have "lost interest" in the board. Any info >> about Avnet's support practices would be useful. > > I ordered one mid-September when the leadtime was "1 week". That sounded a little suspicious so I went to web chat support and got "4 weeks" as the real leadtime. > > It does sound like they're preparing a new rev. Or maybe they're preparing something much more expensive... http://linuxgizmos.com/tiny-arm-plus-fpga-sbc-gains-beefier-fpga/Article: 156052
On 11/13/2013 6:43 AM, alb wrote: > Hi Rick, > > On 08/11/2013 15:47, rickman wrote: > [] >>> According to the FAE it is possible to configure the internal weak >>> pull-up resistor on the PIN configuration and profit of the same >>> mechanism described in the AN I was referring to >>> (http://www.actel.com/documents/LPF_AC380_AN.pdf), therefore >>> *without* the need of an additional external pull up resistor. >> >> The app note goes into great detail about the timing of VCC and VCCI. >> In this discussion I believe they are talking about the input from >> the IBUF (RST_p) when they say, "The I/Os are tristated and the core >> logic detects '1' on the inputs from the boundary scan register >> (BSR)." It is not clear what sets the value in the BSR. It is also >> not clear how this determines the value of the RST_p signal. > > Between the I/O Bank and the FPGA core there's the BSR mandated by the > IEEE-1149.1 standard (JTAG) that you can control during programming. I'm > trying to look for 'default' values, but that is not essential since > when both VCC and VCCI will be above the functional voltage level the > I/O will first drive the input and 200ns later the output, resulting in > the transition '1'->'0' on RST_p which, in turns, generates a transition > '0'->'1' on RST_n, to be used internally as an active low reset. > >> This entire circuit seems to depend on VCC reaching "its functional >> voltage level" before VCCI. Do you know that this is true for your >> board? > > Actually you do not need to have VCC functional *before* VCCI. I paste > here an excerpt from the app note: > > (pag.2) >> Before the start of power-up, all the I/Os are tristated. The I/Os >> remain tristated during the power-up until the last supply (being >> either VCCIBx or VCC) is powered to its functional activation voltage >> level. After the last supply reaches the functional voltage level, >> the outputs of the active I/O bank exits the tristate mode and drive >> the logic at the input of the output buffer. Similarly, the input >> buffers of the active I/O bank passes the external logic into the >> FPGA fabric once the last supply reaches its functional voltage >> level. The behavior of user I/Os is independent of the VCC and VCCIBx >> power-up sequence I hope all this is clear to you, it is not clear to me. But if it works, then great. There's your solution. Will you have to prove to someone that this will work in a real system by analyzing the vendor's documents? That might be a bit tough. BTW, what is the fabric logic doing while all this Vcc ramping is going on. What does it do if the logic VCC ramps up before VCCI does? I guess if the I/Os are not enabled it doesn't matter much what it does if it gets a reset pulse before the outputs are enabled. Can you assure that? -- RickArticle: 156053
On 11/12/13, 5:28 AM, eyecatcherdear@gmail.com wrote: > @Tim Wescott: Yes they have to be generated on core. Actually I need > these clocks to implement 3/4 punctured coding with output data rate > as 150MHz. 150 and 112.5 are not of very high precision when > generated from one core. > > @Richard Damon: Yeah I agree to that. But atleast closer. I am going > to try your method but you said "internal frequencey of 450.016 MHz > (14.063*32) and then divide that by 3 and 4 for the two high speed > clocks, which puts them less than 36 ppm high." I don't understand > the last part. Why is it required to put them less than 36ppm high? My comment on less than 36 ppm high is that the actual number for this is a bit less than 36 ppm, so it show the error that you WILL get, you need to see if that is good enough. > > Is there any document you can recommend for clock generation which > discusses the PLL clock cores in detail? I get confused with multiple > clock generation. > > I was wondering if I cascade two cores? The user guide says it > allows to generate 6 clocks that means 2 cores. I tried that using > one to generate 150MHz and then generate 112.5 and 14.063 from 150 > but the last 2 clocks did not generate. > The chip document should have the information needed.Article: 156054
Hi Rick, On 14/11/2013 02:10, rickman wrote: >> [] >>> The app note goes into great detail about the timing of VCC and VCCI. >>> In this discussion I believe they are talking about the input from >>> the IBUF (RST_p) when they say, "The I/Os are tristated and the core >>> logic detects '1' on the inputs from the boundary scan register >>> (BSR)." It is not clear what sets the value in the BSR. It is also >>> not clear how this determines the value of the RST_p signal. >> >> Between the I/O Bank and the FPGA core there's the BSR mandated by the >> IEEE-1149.1 standard (JTAG) that you can control during programming. I'm >> trying to look for 'default' values, but that is not essential since >> when both VCC and VCCI will be above the functional voltage level the >> I/O will first drive the input and 200ns later the output, resulting in >> the transition '1'->'0' on RST_p which, in turns, generates a transition >> '0'->'1' on RST_n, to be used internally as an active low reset. >> >>> This entire circuit seems to depend on VCC reaching "its functional >>> voltage level" before VCCI. Do you know that this is true for your >>> board? >> >> Actually you do not need to have VCC functional *before* VCCI. I paste >> here an excerpt from the app note: >> >> (pag.2) >>> Before the start of power-up, all the I/Os are tristated. The I/Os >>> remain tristated during the power-up until the last supply (being >>> either VCCIBx or VCC) is powered to its functional activation voltage >>> level. After the last supply reaches the functional voltage level, >>> the outputs of the active I/O bank exits the tristate mode and drive >>> the logic at the input of the output buffer. Similarly, the input >>> buffers of the active I/O bank passes the external logic into the >>> FPGA fabric once the last supply reaches its functional voltage >>> level. The behavior of user I/Os is independent of the VCC and VCCIBx >>> power-up sequence > > I hope all this is clear to you, it is not clear to me. But if it > works, then great. There's your solution. I do not get what is not clear for you, it might be I'm missing something. > Will you have to prove to > someone that this will work in a real system by analyzing the vendor's > documents? That might be a bit tough. Not more than proving that any other piece of the logic works. My system is relying on the internal PLL properly working and I only have the datasheet to consult. What else should i be considering? > BTW, what is the fabric logic doing while all this Vcc ramping is going > on. What does it do if the logic VCC ramps up before VCCI does? I > guess if the I/Os are not enabled it doesn't matter much what it does if > it gets a reset pulse before the outputs are enabled. Can you assure that? The I/O are tristated until the *last* supply is powered. What the internal logic does before that point is kind of useless to speculate on since whichever state will end up with it will come back to a known one after reset.Article: 156055
On 11/14/2013 11:24 AM, alb wrote: > Hi Rick, > > On 14/11/2013 02:10, rickman wrote: >>> [] >>>> The app note goes into great detail about the timing of VCC and VCCI. >>>> In this discussion I believe they are talking about the input from >>>> the IBUF (RST_p) when they say, "The I/Os are tristated and the core >>>> logic detects '1' on the inputs from the boundary scan register >>>> (BSR)." It is not clear what sets the value in the BSR. It is also >>>> not clear how this determines the value of the RST_p signal. >>> >>> Between the I/O Bank and the FPGA core there's the BSR mandated by the >>> IEEE-1149.1 standard (JTAG) that you can control during programming. I'm >>> trying to look for 'default' values, but that is not essential since >>> when both VCC and VCCI will be above the functional voltage level the >>> I/O will first drive the input and 200ns later the output, resulting in >>> the transition '1'->'0' on RST_p which, in turns, generates a transition >>> '0'->'1' on RST_n, to be used internally as an active low reset. >>> >>>> This entire circuit seems to depend on VCC reaching "its functional >>>> voltage level" before VCCI. Do you know that this is true for your >>>> board? >>> >>> Actually you do not need to have VCC functional *before* VCCI. I paste >>> here an excerpt from the app note: >>> >>> (pag.2) >>>> Before the start of power-up, all the I/Os are tristated. The I/Os >>>> remain tristated during the power-up until the last supply (being >>>> either VCCIBx or VCC) is powered to its functional activation voltage >>>> level. After the last supply reaches the functional voltage level, >>>> the outputs of the active I/O bank exits the tristate mode and drive >>>> the logic at the input of the output buffer. Similarly, the input >>>> buffers of the active I/O bank passes the external logic into the >>>> FPGA fabric once the last supply reaches its functional voltage >>>> level. The behavior of user I/Os is independent of the VCC and VCCIBx >>>> power-up sequence >> >> I hope all this is clear to you, it is not clear to me. But if it >> works, then great. There's your solution. > > I do not get what is not clear for you, it might be I'm missing something. There is language in the documents you have provided that is not clear. They talk about the boundary scan logic but don't explain how this impacts the start up operation. >> Will you have to prove to >> someone that this will work in a real system by analyzing the vendor's >> documents? That might be a bit tough. > > Not more than proving that any other piece of the logic works. My system > is relying on the internal PLL properly working and I only have the > datasheet to consult. What else should i be considering? But you *aren't* relying on the data sheet. You are relying on an app note that seems to have gaps from what I have seen. I just can't fully grasp how the chip is expected to operate. They have boundary scan logic which has to be reset on power up. Where does that reset come from? Does the boundary scan logic impact this reset strategy at all? Can you show this from the documentation? >> BTW, what is the fabric logic doing while all this Vcc ramping is going >> on. What does it do if the logic VCC ramps up before VCCI does? I >> guess if the I/Os are not enabled it doesn't matter much what it does if >> it gets a reset pulse before the outputs are enabled. Can you assure that? > > The I/O are tristated until the *last* supply is powered. What the > internal logic does before that point is kind of useless to speculate on > since whichever state will end up with it will come back to a known one > after reset. The IOs are tristated, but what is going on with the inputs? This is all being explained piecemeal so I can't see the full picture to know that all of the timing works. Also realize that I read your post and try to remember what you have written. Then I don't think about this for days until the next post. So I don't remember all the details. If you have explained something a week ago I have long since forgotten it. If you are happy, then it doesn't matter if I understand it. But from what you have said, there will be some sort of review of your approach. You need to be able to justify all this adequately for the review. -- RickArticle: 156056
Hi, I try to implement a DDR3 hard memory controller in a Cyclone v device a 5CGXFC3B6F23C7. I created an DDR3 hard memory controller IP core with the Megawizard, integrated the core in my design and added my design files in Quartus. The fitter of Quartus gives following error message Error (15332): Port SHIFTEN of cyclonev_pll_reconfig "HeadTop:I_HeadTop|DDR3Controller:I_MemCtrlBlk|Ddr3MemCtrl:Ddr3MemCtrl_1|Ddr3MemCtrl_000 2:ddr3memctrl_inst|Ddr3MemCtrl_pll0:pll0|pll1~PLL_RECONFIG" has 11 connections, but the maximum bus width of port SHIFTEN is 9 In the file Ddr3MemCtrl_pll0 there are 11 generic_pll instances and as far as I know the Cyclone Pll has only 9 clock outputs so I assume the error message refers to this and barks about the two additional clock outputs. In the Megawizard there is no switch to select the number of clock outputs of the hard memory controller. I tried to synthesise the example created by the Megawizard, but the funny thing is this example is not for the Cyclone V device I specified in Quartus and the fitter ends with an error message too. This time not about the Pll but about some errors with output pins. So my question is: Has anybody implemented successfully a design with a DDR3 hard memory controller in a Cyclone v device or stumbled on the same error message as above. Btw. I use Quartus 13.1 according to Altera the latest version but IMHO not the greatest. RobertArticle: 156057
W dniu 2013-11-15 13:30, baum pisze: > Hi, > > I try to implement a DDR3 hard memory controller in a Cyclone v device > a 5CGXFC3B6F23C7. > > I created an DDR3 hard memory controller IP core with the Megawizard, > integrated the core in my design and added my design files in Quartus. > > The fitter of Quartus gives following error message > > Error (15332): Port SHIFTEN of cyclonev_pll_reconfig > "HeadTop:I_HeadTop|DDR3Controller:I_MemCtrlBlk|Ddr3MemCtrl:Ddr3MemCtrl_1|Ddr3MemCtrl_000 > > 2:ddr3memctrl_inst|Ddr3MemCtrl_pll0:pll0|pll1~PLL_RECONFIG" has 11 > connections, but the maximum > bus width of port SHIFTEN is 9 > > In the file Ddr3MemCtrl_pll0 there are 11 generic_pll instances and as > far as I know the Cyclone Pll has only 9 clock outputs so I assume the > error message refers to this and barks about the two additional clock > outputs. > > In the Megawizard there is no switch to select the number of clock > outputs of the hard memory controller. > > I tried to synthesise the example created by the Megawizard, but the > funny thing is this example is not for the Cyclone V device I specified > in Quartus and the fitter ends with an error message too. > This time not about the Pll but about some errors with output pins. > > So my question is: > Has anybody implemented successfully a design with a DDR3 hard memory > controller in a Cyclone v device or stumbled on the same error message > as above. > > Btw. I use Quartus 13.1 according to Altera the latest version but IMHO > not the greatest. > > Robert > Hi Robert, Your descriptiion is too narrow to say something. If you need my help , send to me whole example project, then I will say something more. AdamArticle: 156058
baum <rf.baumgartner@arcor.de> wrote: > Hi, > > I try to implement a DDR3 hard memory controller in a Cyclone v device > a 5CGXFC3B6F23C7. > > I created an DDR3 hard memory controller IP core with the Megawizard, > integrated the core in my design and added my design files in Quartus. > > The fitter of Quartus gives following error message I have no experience with the CycV, but are you sure the pin attributes are set correctly? There's usually a TCL file output by Qsys that you have to run in Quartus to set the pin parameters before synthesis. You only have to run it once (the settings then go into your .qsf file). If you don't do this synthesis may fail because it incorrectly assigns pins and then fails when those pins don't have the right properties. TheoArticle: 156059
Thanks for all that info. I totally understand the PLL phenomenon but the core has a limitation of generating clocks from 0 to 350MHz. I am using Actel Libero IDE evaluation version 9.1. The input clock rate of PROASIC3 is 40MHz. I can't find any such document where more than one core is used to generate clocks or anyway to produce such clocks in actel. (The actel PLL core lets you enter your required frequency and then generates the clock with the highest precision unlike xilinx ISE where you have to place dividers and multipliers). I'll keep looking and trying different approaches with PLL. Thanks anyway for all your help.Article: 156060
Hi Rick, On 15/11/2013 08:20, rickman wrote: [] >>>> (pag.2) >>>>> Before the start of power-up, all the I/Os are tristated. The I/Os >>>>> remain tristated during the power-up until the last supply (being >>>>> either VCCIBx or VCC) is powered to its functional activation voltage >>>>> level. After the last supply reaches the functional voltage level, >>>>> the outputs of the active I/O bank exits the tristate mode and drive >>>>> the logic at the input of the output buffer. Similarly, the input >>>>> buffers of the active I/O bank passes the external logic into the >>>>> FPGA fabric once the last supply reaches its functional voltage >>>>> level. The behavior of user I/Os is independent of the VCC and VCCIBx >>>>> power-up sequence >>> >>> I hope all this is clear to you, it is not clear to me. But if it >>> works, then great. There's your solution. >> >> I do not get what is not clear for you, it might be I'm missing >> something. > > There is language in the documents you have provided that is not clear. > They talk about the boundary scan logic but don't explain how this > impacts the start up operation. Well, it is possible that i misunderstood that part, but reading the app. note again it looks to me that when the I/O is *not* enabled (i.e. prior to both VCC and VCCIBx operational) the fabric logic is driven by the BSR register. Since prior to both VCC and VCCIBx operational the I/O is tristated, I do not care much about what is going on internally since it is not going to affect the I/O. OTOH when both VCC and VCCIBx are operational there's a sequence of 'activation' of the input first and the output secondly which provides the '0'->'1' condition for an active low reset labelled in the document as RST_n. >>> Will you have to prove to >>> someone that this will work in a real system by analyzing the vendor's >>> documents? That might be a bit tough. >> >> Not more than proving that any other piece of the logic works. My system >> is relying on the internal PLL properly working and I only have the >> datasheet to consult. What else should i be considering? > > But you *aren't* relying on the data sheet. You are relying on an app > note that seems to have gaps from what I have seen. I just can't fully > grasp how the chip is expected to operate. They have boundary scan > logic which has to be reset on power up. Where does that reset come > from? Does the boundary scan logic impact this reset strategy at all? The BSR is normally 'reset' through the JTAG port (either synchronously or asynchronously), but does not really matter because when the JTAG is not active the chip drives output from its internal fabric and samples input transparently. > Can you show this from the documentation? Nope, I'm trying to look for the JTAG implementation description of this device, but I'm having hard time to find it. [] >> The I/O are tristated until the *last* supply is powered. What the >> internal logic does before that point is kind of useless to speculate on >> since whichever state will end up with it will come back to a known one >> after reset. > > The IOs are tristated, but what is going on with the inputs? This is > all being explained piecemeal so I can't see the full picture to know > that all of the timing works. Also realize that I read your post and > try to remember what you have written. Then I don't think about this > for days until the next post. So I don't remember all the details. If > you have explained something a week ago I have long since forgotten it. I completely understand. > > If you are happy, then it doesn't matter if I understand it. But from > what you have said, there will be some sort of review of your approach. > You need to be able to justify all this adequately for the review. Yep!Article: 156061
On 11/18/2013 11:13 AM, alb wrote:
> Hi Rick,
>
> On 15/11/2013 08:20, rickman wrote:
>> The IOs are tristated, but what is going on with the inputs? This is
>> all being explained piecemeal so I can't see the full picture to know
>> that all of the timing works. Also realize that I read your post and
>> try to remember what you have written. Then I don't think about this
>> for days until the next post. So I don't remember all the details. If
>> you have explained something a week ago I have long since forgotten it.
>
> I completely understand.
I think in terms of pictures, so I probably wouldn't fully understand
all of this until I saw a timing diagram. Nothing fancy, just something
that shows all the events in a timeline along with the various signals
in the reset chain. I suspect something like this would be good
material for your review. I believe the events are like this...
Vcc _____------------
VccIO ________---------
--or--
Vcc ________---------
VccIO _____------------
-- results --
BSR drives internal logic, High = drives, Lo = not driving
---------________
Inputs enabled
_________--------
Outputs enabled
____________-----
Input to reset logic
xxxxxxxxx---_____
The reset is your reset circuit for the rest of the chip.
Now that I see it in diagram form, I think you have it covered.
--
Rick
Article: 156062Jon Elson wrote: Well, a little bit of an update. I couldn't get xilprog to work, and can't contact the author. I then did get xc3sprog to run and correctly ID a CPLD. So, I'm guessing it could program one, too, but I haven't tried that. But, accessing the parallel port and talking to the JTAG device through a DLC5 (parallel cable III) was way farther than I had gotten with anything else. I think Impact will work if I have the kernel source installed before I try to compile the cable drivers. Also, one big trick I found online is to rename the whole digilent/adept directory. Something in there causes Impact to just terminate when it gets to the cable setup. Since I don't have a Digilent device, that shouldn't affect me. JonArticle: 156063
Hello all Proposed idea from my research to date: Two FPGA encryption modules: Both will have an identical encryption algorit= hm; key management something I need to research further. Bob has plain text message. He, perhaps through a GUI, sends the file to hi= s FPGA 'cryptosystem' via USB which subsequently encrypts the data. Returns= PC as cipher text, he sends data through unsecured network(leased lines, m= icrowave etc).=20 Alice receives message, sends her module which then decrypts the message. I have returned to college to up skill and as such have been given my final= year project. I'm not looking for code, or to be spoon fed, merely looking= to draw on peoples experience and opinion! I have completed embedded syste= ms projects involving microcontrollers, microprocessors in the past but FPG= As are brand spanking new to me. I have agreed with my lecturer, who is hap= py to leave me 'at it' to stick to: FPGAs, cryptography & communications. Again, I will not progress into looking for code etc etc, just honest opini= ons and suggestions, thank you for your time, jyoung Irl. P.s I'm not in the NSA :)Article: 156064
On 11/21/2013 6:04 PM, youngejoe wrote: > Hello all > > Proposed idea from my research to date: > Two FPGA encryption modules: Both will have an identical encryption algorithm; key management something I need to research further. > Bob has plain text message. He, perhaps through a GUI, sends the file to his FPGA 'cryptosystem' via USB which subsequently encrypts the data. Returns PC as cipher text, he sends data through unsecured network(leased lines, microwave etc). > Alice receives message, sends her module which then decrypts the message. > > I have returned to college to up skill and as such have been given my final year project. I'm not looking for code, or to be spoon fed, merely looking to draw on peoples experience and opinion! I have completed embedded systems projects involving microcontrollers, microprocessors in the past but FPGAs are brand spanking new to me. I have agreed with my lecturer, who is happy to leave me 'at it' to stick to: FPGAs, cryptography& communications. > Again, I will not progress into looking for code etc etc, just honest opinions and suggestions, thank you for your time, jyoung Irl. > > P.s I'm not in the NSA :) Interesting idea. That's my opinion. Was there something more specific you had in mind? Maybe an actual question? Oh, before you go too far with your idea, you might want to look up someone named Ralph Zimmermann and his idea, PGP. Just so you know all the issues involved. -- RickArticle: 156065
On 11/21/2013 4:18 PM, rickman wrote: > On 11/21/2013 6:04 PM, youngejoe wrote: >> Hello all >> >> Proposed idea from my research to date: >> Two FPGA encryption modules: Both will have an identical encryption >> algorithm; key management something I need to research further. >> Bob has plain text message. He, perhaps through a GUI, sends the file >> to his FPGA 'cryptosystem' via USB which subsequently encrypts the >> data. Returns PC as cipher text, he sends data through unsecured >> network(leased lines, microwave etc). >> Alice receives message, sends her module which then decrypts the message. >> >> I have returned to college to up skill and as such have been given my >> final year project. I'm not looking for code, or to be spoon fed, >> merely looking to draw on peoples experience and opinion! I have >> completed embedded systems projects involving microcontrollers, >> microprocessors in the past but FPGAs are brand spanking new to me. I >> have agreed with my lecturer, who is happy to leave me 'at it' to >> stick to: FPGAs, cryptography& communications. >> Again, I will not progress into looking for code etc etc, just honest >> opinions and suggestions, thank you for your time, jyoung Irl. >> >> P.s I'm not in the NSA :) > > Interesting idea. That's my opinion. > > Was there something more specific you had in mind? Maybe an actual > question? > > Oh, before you go too far with your idea, you might want to look up > someone named Ralph Zimmermann and his idea, PGP. http://en.wikipedia.org/wiki/Phil_Zimmermann Just so you know all > the issues involved. >Article: 156066
* chthon <jurgen.defurne@gmail.com> wrote: > Thanks for the answers. I will keep what I have now of floorplanning, > because I like to have a clean result (ISE seems to throw stuff around > like an expanding gas cloud), but I will keep it at that. I now get > 190 MHz, I do not have a spec, but I wanted to know how fast I > (clockwise) I could make my design. And it is now mostly hampered > through the fact that I use 64k bytes of block RAM, which I really had > to constrain, because without this it uses block RAM in weird places. > > Regards, > > Jurgen Hi Jurgen. Sorry to join the party late. I tend to buck the conventional wisdom on things like this. I did my first programmable logic design back in the 1980's when we used PALs (22V10, etc.) Generally you took *total* control of your design. You could use equations, but even when I did I liked knowing exactly what was going on with each and every fuse. I miss those days - the modern trend seems to be for us to "program hardware"; it all is starting to feel like software design. I still like to floor plan tight little units of logic. Everyone here may be right, but my answer to the "if the tools will get you there, why bother?" is... "Because I can." -- KipArticle: 156067
* GaborSzakacs <gabor@alacron.com> wrote: > Philipp Klaus Krause wrote: >> 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. >>> >> >> IANAL, but AFAIK, reproducing instruction set and cycle count exactly is >> OK, unless some of the instructions are patented. Patents expire after >> at most 20 years in any part of the world that I know of, so with a >> 35-year-old CPU you should be ok. >> >> Philipp > > I think you need to be careful. While patents do expire (patents from > 35 years ago expired after 17 years IIRC), copyrights generally do not. > On the other hand it would be unusual for the owners of such old > copyrights to pursue legal action against you unless you were making > a lot of these devices. Still you're better off getting legal advice > from someone who knows more about these issues, especially if you're > intending to make significant money from this copying effort. > > -- > Gabor I don't think you can copyright an instruction set, can you? I thought that some of the "classic" reverse engineering precedents had addressed that. Similar to the old "clean room BIOS reverse engineering" exercises. I am not a lawyer, and no one should take this as proper legal advice, but I believe if you design the processor logic in an "untainted" way (i.e., you don't literally steal circuitry or microcode) then you are free to design a gadget that uses any instruction set you wish. -- KipArticle: 156068
On 11/21/2013 7:17 PM, Kip Ingram wrote: > * GaborSzakacs<gabor@alacron.com> wrote: >> Philipp Klaus Krause wrote: >>> 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. >>>> >>> >>> IANAL, but AFAIK, reproducing instruction set and cycle count exactly is >>> OK, unless some of the instructions are patented. Patents expire after >>> at most 20 years in any part of the world that I know of, so with a >>> 35-year-old CPU you should be ok. >>> >>> Philipp >> >> I think you need to be careful. While patents do expire (patents from >> 35 years ago expired after 17 years IIRC), copyrights generally do not. >> On the other hand it would be unusual for the owners of such old >> copyrights to pursue legal action against you unless you were making >> a lot of these devices. Still you're better off getting legal advice >> from someone who knows more about these issues, especially if you're >> intending to make significant money from this copying effort. >> >> -- >> Gabor > > I don't think you can copyright an instruction set, can you? I thought > that some of the "classic" reverse engineering precedents had addressed > that. Similar to the old "clean room BIOS reverse engineering" > exercises. Copyright applies to the expression of an artistic work. So no, an instruction set can not be copyrighted. However, the nemonics for opcodes can. That is why Zilog had to use a different assembler for the Z80 even though it was binary upward compatible with the 8080. -- RickArticle: 156069
* rickman <gnuarm@gmail.com> wrote: > On 11/21/2013 7:17 PM, Kip Ingram wrote: >> * GaborSzakacs<gabor@alacron.com> wrote: >>> Philipp Klaus Krause wrote: >>>> 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. >>>>> >>>> >>>> IANAL, but AFAIK, reproducing instruction set and cycle count exactly is >>>> OK, unless some of the instructions are patented. Patents expire after >>>> at most 20 years in any part of the world that I know of, so with a >>>> 35-year-old CPU you should be ok. >>>> >>>> Philipp >>> >>> I think you need to be careful. While patents do expire (patents from >>> 35 years ago expired after 17 years IIRC), copyrights generally do not. >>> On the other hand it would be unusual for the owners of such old >>> copyrights to pursue legal action against you unless you were making >>> a lot of these devices. Still you're better off getting legal advice >>> from someone who knows more about these issues, especially if you're >>> intending to make significant money from this copying effort. >>> >>> -- >>> Gabor >> >> I don't think you can copyright an instruction set, can you? I thought >> that some of the "classic" reverse engineering precedents had addressed >> that. Similar to the old "clean room BIOS reverse engineering" >> exercises. > > Copyright applies to the expression of an artistic work. So no, an > instruction set can not be copyrighted. However, the nemonics for > opcodes can. That is why Zilog had to use a different assembler for the > Z80 even though it was binary upward compatible with the 8080. > > -- > > Rick Yeah, that makes sense... So you can functionally duplicate a processor, but not "artistically." Good distinction... -- KipArticle: 156070
On Thu, 21 Nov 2013 18:18:36 -0500, rickman wrote: > On 11/21/2013 6:04 PM, youngejoe wrote: >> Hello all >> >> Proposed idea from my research to date: >> Two FPGA encryption modules: Both will have an identical encryption >> algorithm; key management something I need to research further. >> Bob has plain text message. He, perhaps through a GUI, sends the file >> to his FPGA 'cryptosystem' via USB which subsequently encrypts the >> data. Returns PC as cipher text, he sends data through unsecured >> network(leased lines, microwave etc). >> Alice receives message, sends her module which then decrypts the >> message. >> >> [snip] >> >> Again, I will not progress into looking for code etc etc, just honest >> opinions and suggestions, thank you for your time, jyoung Irl. >> >> P.s I'm not in the NSA :) > > Interesting idea. That's my opinion. The only proper way to do cryptography, in mine. Keeping the keys on the same machine as the rest of your software is just asking for trouble. I have a plan to eventually produce a device with a similar concept as the above, just in a RFID package and implantable. So that stealing your crypto keys becomes a tad bit more complicated. :) Also, I am not sure about full-blown encryption on the crypto-device, but signing, verifying, and small time encryption (like asimetrically encrypting/decrypting simetrical keys and similar) are certainly viable.Article: 156071
I've been wondering if there could be a successful (not too large,
reasonable clock frequency) soft-core FPGA version of a low end variant of
the Mill. One issue with FPGAs is that only two-port memory is available.
It's not so hard to make extra read ports with these, but extra write ports
are a big problem. This pretty much precludes any sane implementation of
Tomasulo's algorithm for OOE.
If I understand "the belt" properly, the number of write ports is set to
just the number of pipelines (or maybe to two to support the spilling). The
pipes need to be able to read from anywhere, but we can do that with extra
read ports and one extra mux stage. Anyway, it seems like a nice way to get
superscalar on an FPGA.
Perhaps Out of the Box Computing has an FPGA version now already for bring
up? Very curious what clock frequency they are getting..
--
/* 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: 156072On 11/22/2013 7:20 AM, Joseph H Allen wrote: > I've been wondering if there could be a successful (not too large, > reasonable clock frequency) soft-core FPGA version of a low end variant of > the Mill. One issue with FPGAs is that only two-port memory is available. > It's not so hard to make extra read ports with these, but extra write ports > are a big problem. This pretty much precludes any sane implementation of > Tomasulo's algorithm for OOE. > > If I understand "the belt" properly, the number of write ports is set to > just the number of pipelines (or maybe to two to support the spilling). The > pipes need to be able to read from anywhere, but we can do that with extra > read ports and one extra mux stage. Anyway, it seems like a nice way to get > superscalar on an FPGA. > > Perhaps Out of the Box Computing has an FPGA version now already for bring > up? Very curious what clock frequency they are getting.. > We're working on an FPGA, but it's behind patents, fund raising, and talks, so it won't be soon :-( As for your technical question, I am a software guy and don't know the innards of FPGAs so I have bounced your question to our hardware team and will post their answer. IvanArticle: 156073
> Interesting idea. That's my opinion. >=20 >=20 >=20 > Was there something more specific you had in mind? Maybe an actual=20 >=20 > question? >=20 >=20 >=20 > Oh, before you go too far with your idea, you might want to look up=20 >=20 > someone named Ralph Zimmermann and his idea, PGP. Just so you know all= =20 >=20 > the issues involved. >=20 >=20 >=20 > --=20 >=20 >=20 >=20 > Rick Thanks for your reply. The issue I'm having is FPGA knowledge tbh. In resea= rch mode, still trying to develop a good, real concept. For example, an microcontroller project. I design and build my circuit on b= readboards. Write (eg) embedded c and compile this into machine code using = Keil uVision. I then insert my MCU in an in system programmer such as 'data= man programmer' which will send the compiled machine code to the MCU which = I can then insert my breadboard and see if the project works as planned! With FPGAs, for the above mentioned project, would I would require two deve= lopment boards connected to PC1 and PC2? My initial concept was to use 2 FP= GAs resembling 2 flash drives. PGP is very interesting - employing both asymmetric and symmetric encryptio= n as well as digital signatures etc. I like the idea behind it. As its soft= ware based, would it be difficult resembling it in hardware, say on FPGAs? The main guideline I'm trying to stick is an FPGA based cryptosystem. Thank= sArticle: 156074
We're into this signal processing project, using a microZed/ZYNQ thing as the compute engine. After a week or so of work by an FPGA guy and a programmer, we can now actually read and write an FPGA register from a C program, and wiggle a bit on a connector pin. Amazingly, the uZed eval kit does not include a demo of this, and the default boot image does not configure the FPGA! We're using their build tools to embed the FPGA config into the boot image. We'd really like to be able to have a C program read a bitstream file and reconfigure the FPGA, but we haven't been able to figure that out. If we run a C program that wiggles a pin as fast as it can, we can do a write to the FPGA register about every 170 ns. Without any attempts at optimization (like dedicating the second ARM core to the loop) we see stutters (OS stealing our CPU) that last tens or hundreds of microseconds, occasionally a full millisecond. That might get worse if we run TCP/IP sessions or host web pages or something, so dedicating the second ARM to realtime stuff would be good. -- John Larkin Highland Technology Inc www.highlandtechnology.com jlarkin at highlandtechnology dot com Precision electronic instrumentation Picosecond-resolution Digital Delay and Pulse generators Custom timing and laser controllers Photonics and fiberoptic TTL data links VME analog, thermocouple, LVDT, synchro, tachometer Multichannel arbitrary waveform generators
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