Nice that they're back at the same price. Sometimes they come back more expensive. It will be interesting to see how long those 900 last.
Apart from "whether 1 cog would fit in 12% more gates", the question was how fast would it run in a cyclone V vs a cyclone IV
The Terasic boards ($179, $299) also seem close now, too.
The awesome thing about Parallax doing their own A7 board would be if it could be in the same form factor as the eventual P2 module (eg PCIE connector). That way we could get a proper head start on development rather than building limited lifetime adapters etc
The awesome thing about Parallax doing their own A7 board would be if it could be in the same form factor as the eventual P2 module (eg PCIE connector). That way we could get a proper head start on development rather than building limited lifetime adapters etc
intel has set a good example with their SD sized computer - not sure how attainable that would be, but I see BGA memory is 8mm x 8mm so small is a good aspiration.
Mine showed up today. (Indicated it was on order in you recruiting thread)
They are cute, tiny things! I'm used to looking at my DE0 with its face guard and brass legs.
Apart from "whether 1 cog would fit in 12% more gates", the question was how fast would it run in a cyclone V vs a cyclone IV
Last I heard Chip was struggling to 'beat the tools into submission' for a proper Cyclone V build.
MHz and fit info would be very interesting on the whole range of Cyclone V devices.
Last I heard Chip was struggling to 'beat the tools into submission' for a proper Cyclone V build.
MHz and fit info would be very interesting on the whole range of Cyclone V devices.
I filled out a service request with Altera to ask them what I can do about the multicycle-assignment destination registers getting renamed via optimization to compile-time generated names, and then missing out on the multicycle accommodations. Someone got back to me and said that there was no way to stop this from happening, but I could go into each configuration, post-compile, and give the assignments there. That's a really poor way to try to solve the problem, though, and they know it, so they have submitted a feature request to maintain register names through optimization stages so that multicycle assignments will still hold.
By compiling simpler-case modules for Cyclone V, I got the sense that Cycone V is going to run almost 30% faster than the Cyclone IV chips we are now using.
I filled out a service request with Altera to ask them what I can do about the multicycle-assignment destination registers getting renamed via optimization to compile-time generated names, and then missing out on the multicycle accommodations. Someone got back to me and said that there was no way to stop this from happening, but I could go into each configuration, post-compile, and give the assignments there. That's a really poor way to try to solve the problem, though, and they know it, so they have submitted a feature request to maintain register names through optimization stages so that multicycle assignments will still hold.
So this 'keep names' works ok in Cyclone IV, but they have broken it on Cyclone V ? That's a pretty large 'oops' if true.
It's a strange way to have a front-end style failure ?
Surely most of their power users (aka noisiest customers) will need this working ?
By compiling simpler-case modules for Cyclone V, I got the sense that Cycone V is going to run almost 30% faster than the Cyclone IV chips we are now using.
Good, about what one would hope from a new family iteration
So this 'keep names' works ok in Cyclone IV, but they have broken it on Cyclone V ? That's a pretty large 'oops' if true.
It's a strange way to have a front-end style failure ?
Surely most of their power users (aka noisiest customers) will need this working ?
Good, about what one would hope from a new family iteration
Cyclone IV devices let you use the DSP blocks (multipliers, in our case) as asynchronous circuits, whereas Cyclone V forces use of their DSP blocks' input registers. So, our named registers that fed the multipliers got converted into the DSP blocks' compile-time-named registers. Multicycle assignments were then ignored, because the associated register names were missing.
Cyclone IV devices let you use the DSP blocks (multipliers, in our case) as asynchronous circuits, whereas Cyclone V forces use of their DSP blocks' input registers. So, our named registers that fed the multipliers got converted into the DSP blocks' compile-time-named registers. Multicycle assignments were then ignored, because the associated register names were missing.
That's sounding a little more like a special use case, which could explain how they missed the consequences...?
Do the compile-time names, always follow a consistent algorithm ? - it may be a script could patch around the problem, while they are applying a fix ?
Comments
Obvious question, is can the latest build fit into this FPGA ?
Apart from "whether 1 cog would fit in 12% more gates", the question was how fast would it run in a cyclone V vs a cyclone IV
The Terasic boards ($179, $299) also seem close now, too.
The awesome thing about Parallax doing their own A7 board would be if it could be in the same form factor as the eventual P2 module (eg PCIE connector). That way we could get a proper head start on development rather than building limited lifetime adapters etc
intel has set a good example with their SD sized computer - not sure how attainable that would be, but I see BGA memory is 8mm x 8mm so small is a good aspiration.
jmg
Leon
Ale (me)
They are cute, tiny things! I'm used to looking at my DE0 with its face guard and brass legs.
Last I heard Chip was struggling to 'beat the tools into submission' for a proper Cyclone V build.
MHz and fit info would be very interesting on the whole range of Cyclone V devices.
I've got a BeMicro CV, too. BTW, I'm most curious to know what you have planned regarding the P1.
I filled out a service request with Altera to ask them what I can do about the multicycle-assignment destination registers getting renamed via optimization to compile-time generated names, and then missing out on the multicycle accommodations. Someone got back to me and said that there was no way to stop this from happening, but I could go into each configuration, post-compile, and give the assignments there. That's a really poor way to try to solve the problem, though, and they know it, so they have submitted a feature request to maintain register names through optimization stages so that multicycle assignments will still hold.
By compiling simpler-case modules for Cyclone V, I got the sense that Cycone V is going to run almost 30% faster than the Cyclone IV chips we are now using.
So this 'keep names' works ok in Cyclone IV, but they have broken it on Cyclone V ? That's a pretty large 'oops' if true.
It's a strange way to have a front-end style failure ?
Surely most of their power users (aka noisiest customers) will need this working ?
Good, about what one would hope from a new family iteration
Cyclone IV devices let you use the DSP blocks (multipliers, in our case) as asynchronous circuits, whereas Cyclone V forces use of their DSP blocks' input registers. So, our named registers that fed the multipliers got converted into the DSP blocks' compile-time-named registers. Multicycle assignments were then ignored, because the associated register names were missing.
That's sounding a little more like a special use case, which could explain how they missed the consequences...?
Do the compile-time names, always follow a consistent algorithm ? - it may be a script could patch around the problem, while they are applying a fix ?