<cr1901_modern>
whitequark: Of course, the easy answer is to just "split spartan3 into it's own file". But the amount of duplication is pretty massive. There are a few primitives missing from S3 that are in S6 (I'll list them in a sec), and... that's it
<cr1901_modern>
uhhhh, yea, that wasn't a question
<cr1901_modern>
errr, is there an easy way you can think of to distinguish s3 and s6 platforms that "xilinx_spartan6.py" can inspect? Or don't bother and just eat the code duplication? I think we agreed on the latter
<whitequark>
don't the chip names start from some specific code?
<whitequark>
like device.upper().startswith("XC3")
<cr1901_modern>
yup that works. Just wasn't sure if you'd like that
<cr1901_modern>
missing primitives: IDDR2, ODDR2
<whitequark>
well i am pretty sure 3E has DDR
<whitequark>
so you'll have to figure out which primitives should be used instead
<cr1901_modern>
yea there's something in the manual
<cr1901_modern>
but ironically, grepping for "DDR" said no results
<whitequark>
actually the datasheet says IDDR2 and ODDR2 are present
<cr1901_modern>
it's a freak accident I noticed the minute you sent that msg
<cr1901_modern>
whitequark: Oh, I see... was looking at Spartan 3 manual. When I look at Spartan 3e manual, I find {I,O}DDR2
<whitequark>
here's something weird
<whitequark>
>The C0 or C1 alignment feature of the ODDR2 flip-flop,
<whitequark>
originally introduced in the Spartan-3E FPGA family, is not
<whitequark>
software.
<whitequark>
recommended or supported in the ISE development
<whitequark>
why?
<cr1901_modern>
Ditto with 3A
<cr1901_modern>
I only care about 3A, fwiw
<cr1901_modern>
huh
<whitequark>
so there *isn't* IDDR2 in 3A?
<cr1901_modern>
> Ditto with 3A
<cr1901_modern>
Sorry, let me try again
<cr1901_modern>
3a and 3e both have {I,O}DDR2
<whitequark>
ohhhh: > It has been confirmed that the alternative "C0" and "C1" aren't implemented in ISE for th Spartan 3A even if the IOB might be capable.
<whitequark>
that's... kind of garbage
<cr1901_modern>
I mean, it _barely_ made sense to be using S3 when I got this FPGA in 2015
<cr1901_modern>
so I'm not surprised
<whitequark>
oh I see: >For all Spartan-3E and ES silicon of Spartan-3A, ODDR2 with DDR_ALIGNMENT set to C0 or C1 is not supported in the software and might result in data corruption when implemented in the hardware. For Production silicon of Spartan-3A, C0 and C1 alignment is fully functional and supported.
<whitequark>
ok
<whitequark>
so 3A is fine but not 3E
<whitequark>
then you'll need to detect 3A
<cr1901_modern>
there will be an "a" suffix
<cr1901_modern>
so endswith("a")
<whitequark>
yes
<cr1901_modern>
I actually have a spartan-3e board, but as I never got the JTAG programmer required (and refuse to shell out $50 for one) I never used it
<cr1901_modern>
damn thing was a parallel port programmer lmfao
tweakoz has joined #m-labs
<cr1901_modern>
whitequark: I don't even have a S3 (without A or E) board to test. Is it okay for now to only support 3e and 3a (disabling 3e's broken features)? For perspective, the 3A board I wanted to add _is_ still produced as of today.
<whitequark>
cr1901_modern: well if you can't test 3e then you shouldn't claim to support 3e
<whitequark>
much less 3
<cr1901_modern>
fair enough. It just sounded like you wanted a guard for 3a
<cr1901_modern>
and 3e
<cr1901_modern>
_I_ don't really care about supporting 3e :P
<whitequark>
then screw it
<cr1901_modern>
works for me :P. Then 3a support should be a literally one line change in "xilinx_spartan6.py"
<whitequark>
that sounds doubtful
<whitequark>
even a function to classify devices would be longer
<cr1901_modern>
yea, ignore me- I misspoke
<cr1901_modern>
in terms of _templates_, I have to add one line (use_new_parser=YES. This matches omigen's behavior for both s6 and s3)