sb0 changed the topic of #m-labs to: ARTIQ, Migen, MiSoC, Mixxeo & other M-Labs projects :: fka #milkymist :: Logs http://irclog.whitequark.org/m-labs
<cr1901_modern>
FelixVi: Okay, I can duplicate your flterm woes on my machine on Cygwin
<cr1901_modern>
that's good news, for some metric of good
<FelixVi>
cr1901_modern: Ah, well that's good :0
<FelixVi>
it's linked to async io that cygwin does in a way different from *nix and win
<FelixVi>
I'm currently looked at DDR timing constraints to see if I can get it to run faster
davidc__ has joined #m-labs
<davidc__>
sb0, whitequark (and whoever else worked on it) - ionpak/spectrapak look really neat! Looking for any help/contributions? I might build an ionpak board and try to source one of those cheap gauges to act as a cross-check with my current gauging
<FelixVi>
ok, I think the problem is that ddrphy slices are placed pretty close to the iobs, but interface slices are pretty far away
<FelixVi>
that might be a problem because the cpu freq is slow in this case, so the router thinks this doesn't matter
<whitequark>
davidc__: sure, go ahead!
<davidc__>
whitequark: do you happen to know a good way to buy one of those cheap taobao gauges to canada? (Otherwise, I'll just try some sketchy taobao shoppers/reshippers)
<whitequark>
reshippers are the only way
<davidc__>
whitequark: Ok. I'll ask around for a reliable one.
<davidc__>
whitequark: Does the current firmware do anything re: gauge sensitivity?
<cr1901_modern>
the one for the programmer flash proxies
<FelixVi>
the first is to make sure I can run xc3sprog on windows as well
<cr1901_modern>
xc3sprog should be compileable on cygwin?
<davidc__>
whitequark: I'm fairly sure it doesn't - pages.rs:{81,55} have the conversions from current ratio to pressure, but it includes a constant that I'm not certain about
<cr1901_modern>
In any case my opinion is don't mix and match cygwin and Windows unless you absolutely have to
<cr1901_modern>
(Xilinx ISE being a case where you absolutely have to)
<FelixVi>
cr1901_modern: you can install ISE in cygwin
<davidc__>
whitequark: actually, nevermind, the conversion could be plausible if the sensitivity is on the high side
<cr1901_modern>
FelixVi: Why didn't you tell me this from the beginning? And I haven't seen any indication that ISE binary understands Cygwin paths
<davidc__>
sb0 / whitequark - do you recall how the code/gauge was calibrated?
<cr1901_modern>
FelixVi: We have to agree on what build environment is supported. I can't support every possible combination of build() via Migen on Windows.
<cr1901_modern>
I supposed it doesn't matter, b/c tonight I learned cygwin actually _does_ understand Windows-style paths.
<FelixVi>
that way, I don't need Cyg to upload code to the lm32
<FelixVi>
drawback is that compiling software requires Cygwin
<FelixVi>
but maybe I can just setup a raspberry pi in the corner that does that :)
<cr1901_modern>
Then why did you say you could _install_ ISE in cygwin?
<FelixVi>
cr1901_modern: because you can if you want the who build environment in Cygwin
<FelixVi>
it just means we'd need to figure out the asyncio problem in Cygwin
<cr1901_modern>
I can't find _any_ indication that ISE can run successfully in a Cygwin environment
<FelixVi>
but who ever is running Cygwin also runs Windows
<cr1901_modern>
Is that not why we needed sanitize() to begin with?
<FelixVi>
yes, because people with a Windows PC already have ISE installed in Win
<cr1901_modern>
That's not installing ISE in cygwin
<FelixVi>
yes
<cr1901_modern>
you still have to convert all your paths to Windows, call out to cmd.exe to run ISE
<FelixVi>
I guess I don't get why you don't like using Win for what it works for easily and Cygwin what it works for easily
<FelixVi>
migen/misoc are easier to get going in Cygwin
<FelixVi>
ISE and asyncio run just fine in Windows
<cr1901_modern>
B/c its 2**4 combinations I have to support
<cr1901_modern>
I'm not going to be responsible for Migen/Misoc being able to swap between environments like that
<cr1901_modern>
And possible subtle breakages/hacks to make it work
<FelixVi>
yeah, that's perfectly fine
<whitequark>
I don't think we should support Cygwin-based setups at all
<FelixVi>
I'd just say for Windows users, run things the way I do and they work
<FelixVi>
or just say it's not supported, I suppose that works as well
<FelixVi>
but sanitize is all it needs to work, I don't see how that is a major hack/breakage
<sb0>
davidc__, ah great! sure, help/contribution much appreciated.
<cr1901_modern>
I don't see how that is a major hack/breakage <-- it isn't. For now.
<sb0>
davidc__, the gauge sensitivity constants come from the gauge datasheets.
<FelixVi>
cr1901_modern: Right, well if there's any concern about it turning into a problem, we should hold off with the PR and explore potential concerns
<FelixVi>
I'll have to drive home real quick, but will try to get back online in a little bit (1-2h)
<cr1901_modern>
I agree
<FelixVi>
cr1901_modern: Maybe it is best to specify in the readme what build environments are supported and which ones aren't
<FelixVi>
at least I wasn't aware that it'll be so difficult :)
<FelixVi>
anyway, brb
<cr1901_modern>
FelixVi: Well the truth is I never knew. B/c I didn't think to check. B/c I thought I solved this problem by explicitly supporting msys2 a while ago.
<cr1901_modern>
I didn't think that supporting native windows, or cygwin would cause so much pain
<FelixVi>
cr1901_modern: Sorry, I didn't see that
<FelixVi>
I'll be happy to leave my fork up for Win users, at least I'll keep running things that way for a while
<cr1901_modern>
FelixVi: Oh it's not in the readme... in any case, this is good (for some metric of good) so I can figure out what I'm willing to support
<FelixVi>
It'll be hard to convince people to move away from Windows on lab computers because most people rely on some third party drivers that don't come with linux support
<davidc__>
sb0: Ah, OK. I'll spin a board and try to source a cheap BA gauge
<FelixVi>
or the fact that grad student don't have time to learn linux and get things up and running
<davidc__>
and see how it matches to my current penning gauge
<FelixVi>
cr1901_modern: Yeah, if you don't think Cygwin support allows new people to use migen, then don't make it officially supported
<FelixVi>
I really like the idea of having a real Win port if that is something of interest
<cr1901_modern>
FelixVi: It's not that. It's that FOSS on Windows is a huge f***ing mess
<FelixVi>
but it's a lot more work then Cygwin support
<FelixVi>
yeah, well let's keep talking about it
<FelixVi>
I'll be happy to help out if that helps
<sb0>
davidc__, cool. there are a number of things that need to be fixed still, especially in the firmware
<FelixVi>
brb in a little while
<cr1901_modern>
FelixVi: I appreciate that
<sb0>
davidc__, and for the pcb - if you spin a board I can send you a new version with some of the errata fixed
<davidc__>
sb0: I saw the HW errata page, and I'm working on getting the FW building (nightly requires a new feature flag, and the cortex-m package doesn't pull in the updated bare-metal package)
<davidc__>
sb0: cool. I'll ping you once I've sourced a gauge. There's some cheap "Hornet" gauge+controller modules ($50 shipped) on ebay. I might grab one of those and strip it for the gauge
<sb0>
but then you don't know what the parameters are
<sb0>
though I think you can try common values and calibrate with your other gauge
<sb0>
also, a lot of the vacuum equipment on ebay is trash
<davidc__>
sb0: I'd invest in a better tube if I get it working :)
<davidc__>
sb0: all I have to calibrate it to is a penning gauge (also sourced via ebay), so the calibration accuracy on that is ???? :)
<davidc__>
but really I only care about OOM for my application
<sb0>
oom?
<davidc__>
sorry, order of magnitude. I have a SEM with a diff pump that I was unsure about
<davidc__>
(the SEM only has a roughing-side gauge, and assumes the diff-pump is working at a fixed ratio to estimate chamber pressure. I wanted to know whether the chamber was actually at HV to figure out whether certain issues were caused by that)
<cr1901_modern>
sb0, rjo: Does this look reasonable to finish Windoze bikesheeding once and for all?
rohitksingh_work has joined #m-labs
<sb0>
I still think relative paths may be a better solution than calling cygwin programs
FelixVi2 has joined #m-labs
<FelixVi2>
cr1901_modern: in the MSYS2 case, is ISE still installed in Win?
<cr1901_modern>
yes
<cr1901_modern>
In all of then, ISE is installed under C:\Xilinx or whatever
<cr1901_modern>
sb0: Well we can try it. I just have a bad feeling it'll break or Python will get confused trying to calculate a relative path thanks to symlinks making relpaths non unique
<cr1901_modern>
(in case you decide to build with a symlinked dir as a parent)
<sb0>
I don't think migen ever compares paths, so why is that a problem?
<sb0>
and sure, relative paths cannot be compared with a string comparison, even without symlinks
<cr1901_modern>
how do you calculate the rel path in the first place? You need your current dir and the target dir
<FelixVi2>
cr1901_modern: I am really not fixated on using Cygwin over MSYS2 - so if that's easier to do let's go that route
<sb0>
why do you need a relative path between those two, exactly?
<FelixVi2>
sb0: I think I would test the tracer and figure out which configuration works
<FelixVi2>
sb0: then go with that - and there's no mess with any path
<cr1901_modern>
sb0: Oh, erm... I guess you don't
<cr1901_modern>
But what would you make it relative to
<FelixVi2>
sb0: if the tracer self test doesn't work, the user gets a clear message about what's going on
<cr1901_modern>
s/it/your target/
<sb0>
just use whatever the user input is
<sb0>
and the current directory
<sb0>
does cygwin let non-cygwin programs access files in the current directory using relative paths, or is that fucked too?
<cr1901_modern>
I haven't tried it
<cr1901_modern>
but most likely it works
<travis-ci>
m-labs/smoltcp#431 (arp-flood-prevention - 7937011 : whitequark): The build passed.
<FelixVi2>
I compiled code on "cygdrive" from windows earlier - that wasn't a problem
<cr1901_modern>
sb0: Oh I see what you're saying now re: "just use whatever the user input is". That already works in cygwin
<cr1901_modern>
sb0: The problem is what about lm32's source?
<cr1901_modern>
You don't have control over where that lives in the tree
<cr1901_modern>
Which is IIRC what FelixVi2 was compiling when everything went to hell
<cr1901_modern>
_I don't know_ for sure if rel-paths will cause subtle breakage. I just suspect it will based on my experience with bash terminal autocompletion
<cr1901_modern>
shitting the bed if I traverse into a symlinked dir
<sb0>
hm, right, verilog source in external python packages will be a problem
<cr1901_modern>
Example of autocomplete shitting the bed
<sb0>
is cygwin still relevant these days anyway?
<sb0>
I thought newer versions of windows had some sort of linux api?
<cr1901_modern>
sb0: They do. I'm on 7, and can't take advantage of it
<cr1901_modern>
assuming FelixVi2 is as well
<cr1901_modern>
sb0: is cygwin still relevant these days anyway? <-- less so, but some software (OCaml comes to mind) still only support it officially
<cr1901_modern>
So that's the reason I didn't write it off
<cr1901_modern>
IMO, I think they all should be supported, but if forced to choose, Native and MSYS2 as described in my document.
<sb0>
okay, well then there are only two options 1) cygpath 2) copying files
<sb0>
and both are bad
<cr1901_modern>
sb0: Third option is to open /usr/bin/cygwin.dll and just call the C function that does path conversion directly
<cr1901_modern>
which may or may not be worse
<cr1901_modern>
(it _can_ be done in pure Python :)...)
<sb0>
if that function is documented and stable it's potentially a better option
<cr1901_modern>
Alright then. Let me look into that tomorrow morning and get back to you.
<cr1901_modern>
Also TIL Cygwin binaries _do_ understand Windows paths. Idk if I can leverage that into something useful tho.
<sb0>
probably better to keep all the cygwin side (python) using cygwin paths, and just convert to windows to interface with vivado
<cr1901_modern>
That's fair. That will also work for the one potential edge case I can think of- calling yosys as the Xilinx front end.
<cr1901_modern>
(assuming it still works)
<FelixVi2>
Again, if Cygwin turns into a shit show, let's get rid of it
<FelixVi2>
but being able to use the build environment from windows has some value inho
<FelixVi2>
are people using artiq running linux boxes exclusively?
<FelixVi2>
or is NIST in general more linux savvy than average?
<cr1901_modern>
FelixVi2: The truth is- _Idk_ which way is best. They all kinda suck b/c while migen can be used standalone, you opt into some unixy stuff (gcc, make, chmod) when you move to misoc.
<cr1901_modern>
And well, there are multiple ways to make a Windows box act like unix that have been developed over the years that don't necessarily place nice w/ each other
<FelixVi2>
cr1901_modern: Yeah, the only data point I have is that Cygwin seems to work well with fixed paths
<FelixVi2>
and under the limitation that it's python 3.6
<FelixVi2>
Why don't we have me test drive that for a while to see how things play out?
<cr1901_modern>
Well, MSYS2 is gonna have the same problem. I just haven't updated python :D
<FelixVi2>
hehe ;0
<FelixVi2>
I can still submit PRs for platforms and targets etc. - just everything that's build environment independent
<cr1901_modern>
True
<FelixVi2>
To this point I just haven't had a chance to do much beyond that
<FelixVi2>
but I do have a working toolchain now and finally get to do some of the fun stuff
<cr1901_modern>
I prefer msys2; I don't like how you basically opt into "it only works on my machine without some effort".
<cr1901_modern>
(as indicated by the fact I had to send you some dlls manually)
<FelixVi2>
cr1901_modern: You lost me
<cr1901_modern>
msys2 takes some effort to set up, and it's likely that "sending someone only the software the need to _run_ misoc successfully" is going to fail :)
<cr1901_modern>
like it did when I sent you my gcc
<FelixVi2>
yeah, I'd go for minimum effort with windows
<cr1901_modern>
But it's also not fair to make Windows users compile gcc for the same reason; b/c it also takes effort to get gcc compiled
<cr1901_modern>
Not much, but the avg Windoze user isn't going to know how to do it
<FelixVi2>
the fact that people like me use windows means they struggle with linux
<cr1901_modern>
I use it b/c it's what I'm used to, among other things
<FelixVi2>
and while I'm willing to spend time learning, others may not - and I don't think one can just tell them to suck it up :)
<cr1901_modern>
I can certainly live w/ Linux or even *BSD. Just not my preference
<FelixVi2>
IMO, a windows port should be minimal effort to setup, but will likely also be the least flexible
<FelixVi2>
hmm, I get your point
<FelixVi2>
dinner's ready - but I'll keep thinking about it
<FelixVi2>
Win builds and native support is likely the easiest way out - but it takes a lot of effort on your / my / our (whoever does it) end
<FelixVi2>
brb
* cr1901_modern
is calling it quits tonight
<sb0>
what are the advantages of Faraday rotators over liquid crystal panels?
<FelixVi2>
sb0: I think Faraday rotators are directional while lc panels aren't
<sb0>
directional?
<FelixVi2>
so lc panel can't be used as isolators (correct me if I'm wrong)
<FelixVi2>
polarization rotates when passing one way
<FelixVi2>
then it rotates the same direction on the way back
<FelixVi2>
lc panels are just like linear polarizers, but they don't rotate
<FelixVi2>
and you can switch between horizontal and vertical polarization
<sb0>
10/100 Ethernet PHY IP core for FPGA which uses only external passives
<cr1901_modern>
Ahh yes azonenberg has been trying to disturb the natural order as of late
<rqou>
sb0: re faraday rotators: "One crucial difference between a waveplate and a Faraday rotator is that the former is reciprocal and the latter is not reciprocal. So you positively cannot fully realise a Faraday rotator with waveplates."
<sb0>
rqou, but that matters only if you're doing optical isolators or similar?
<sb0>
for simple 1-way polarization rotation, lcd panel is fine?
<rqou>
i think so?
<cr1901_modern>
"So you positively cannot fully realise a Faraday rotator with waveplates." What does this mean?
<rqou>
there is no way to construct a faraday rotator out of only waveplates
<rqou>
but depending on the intended application it may be possible to cheat
<FelixVi2>
cr1901_modern: waveplates are always symmetric because it's just a piece of crystal. a rotator has magnetic fields where "handedness" matters, so it breaks that symmetry
<rqou>
ah neat
<rqou>
didn't know that specific fact
<FelixVi2>
they are cool, but kind of spendy
<FelixVi2>
if you want a cool waveplate, buy a berek unit
<FelixVi2>
those are pretty fun, too
<rqou>
but hacking lcds is also fun
<sb0>
you can make a faraday rotator with a coil of wire and cooking oil
* FelixVi2
is off to bed - good night
FelixVi2 has quit []
<sb0>
I suspect the only reason they are spendy is because all professional optical components are spendy
<cr1901_modern>
I barely understand/remember how light polarization works
<rqou>
lol sb0
<sb0>
chemicals too, e.g. sigma-aldrich or goodfellow are awful
<rqou>
but yes, afaik all professional optics are really really expensive
<rqou>
it's amazing what economies of scale can do though (see: lcd displays, optical drives)
<rqou>
huh another interesting explanation: waveplates have different propagation speeds for different _linear_ polarizations while faraday rotators have different propagation speeds for different _circular_ polarizations
<davidc__>
sb0: I ask because I've been doing a bit of research on coefficients for these things; pretty much everyone specs either 25, 15, 10 torr^-1 (with various papers saying the error bounds on those from gauge-to-gauge are terrible)
<davidc__>
sb0: Also, I found a few north-american/EU suppliers around the $150-300 mark (duniway, filtech, ldsvacuum). Not as cheap as the .cn ones - but not as painful as lesker
<sb0>
I'm not sure how LCD panels work, but they're certainly not waveplates
<sb0>
otherwise they would be wavelength specific
<sb0>
davidc__, for ion gauges? yes, I was looking at filtech too, seems interesting if they're good at UHV
<rqou>
are you sure LCDs aren't wavelength-specific?
rohitksingh_work has quit [Read error: Connection reset by peer]
<sb0>
looking at their ip core, it seems xilinx themselves are struggling with their transceiver trash not being able to generate a 125M clock for gbe ...
<sb0>
and they waste MMCMs on this
rohitksingh has joined #m-labs
<rjo>
125M fabric?
<sb0>
yes
<sb0>
I have an idea... since we're not using the internal 8b10b stuff, we can also run them at 2G and duplicate/discard half the bits
<sb0>
I just wonder if that will cause CDR problems
<GitHub65>
[artiq] sbourdeauducq commented on issue #852: artiq_flash doesn't support Sayma without RTM. You need to edit the OpenOCD script manually if you want to do anything with Sayma AMC alone. https://github.com/m-labs/artiq/issues/852#issuecomment-346400848
<GitHub15>
[artiq] sbourdeauducq commented on issue #852: That comment simply means that writing the RTM bitstream into the flash is not yet supported. By the way, you still need to make a decision regarding the way the RTM FPGA will be loaded. https://github.com/m-labs/artiq/issues/852#issuecomment-346402282
<FelixVi>
I'm trying to add soft float to get printf - what lib is used for __subdf3?
cr1901_modern has quit [Read error: Connection reset by peer]
cr1901_modern has joined #m-labs
<sb0>
compiler-rt I guess
<sb0>
but why is that a problem? it should be there already
<sb0>
is there a bug?
<sb0>
ah, and to use only one MMCM instead of two, the xilinx trash uses clock correction for RX
<sb0>
why make it simple
<cr1901_modern>
m-labs silicon when?
<sb0>
I wonder how many errata there are for transceiver clock correction; surely they cannot have done that right ...
<sb0>
"Xilinx has determined that the Clock Correction feature of the Virtex-5 GTX transceiver can cause data corruption on the Receiver when a clock correction sequence is skipped or added."
<sb0>
why I am not surprised
<key2>
:0
<cr1901_modern>
sb0: You've seen to have nothing but problems w/ Xilinx IP :(. Does Altera/Intel suck too?
<sb0>
Altera transceivers have a physical self-destruct "feature" on some FPGAs
<cr1901_modern>
Self-Initiated Disassembly?
<sb0>
it is automatically activated by old versions of quartus
rohitksingh has quit [Quit: Leaving.]
<FelixVi>
sb0: I'm getting "relocation truncated to fit: R_LM32_CALL against undefined symbol `__subdf3'"
<FelixVi>
libm is linked and found in the Makefile
<FelixVi>
this also doesn't work when trying to make it a bus
<FelixVi>
but the version with only 1 platform request didn't yield an entry in the csr file
<FelixVi>
K, that's working too
<FelixVi>
is there any interest in adding basic examples to the misoc repo? I think I'll document my first steps *somewhere* anyways
<FelixVi>
so, 4 sys_clk cycles are 1 cycle of the CPU, right?
<FelixVi>
so when I run at 25 MHz sys_clk and I toggle an IO every 1M cycles in C, my frequency will be 6.25 Hz
<FelixVi>
at least that's what I measure
<FelixVi>
is there another lm32 version with more pipelining available or is this what you guys actually use?
* cr1901_modern
thinks someone should write docs for misoc
* cr1901_modern
thinks that someone is probably going to be him
<FelixVi>
cr1901_modern: Let me know if I can help ;)
<cr1901_modern>
FelixVi: Will do, but this is a bit down the road
<FelixVi>
yeah, by then I'll have read more of the source
<FelixVi>
Based on what I can see, SoCCore does not have a parameter for different versions
<FelixVi>
I just wanted to make sure that I'm working on the "newest" version of lm32
<cr1901_modern>
rjo wanted me to add some "cleanup" changes in the first of a series of PRs that I needed, so it's kinda fair that >>
<cr1901_modern>
If I'm gonna jam a bunch of PRs thru Migen, I do some cleanup as well
<cr1901_modern>
FelixVi: lm32 is stable and unlikely to be changed except for bug fixes
<cr1901_modern>
(testing the MMU would be nice)
<cr1901_modern>
FelixVi: I _very_ strongly suggest just doing git submodule update --init in misoc and just leaving the lm32 tree alone.
<cr1901_modern>
If you want to play w/ lm32 by itself, the repo is already set up for simulation: https://github.com/m-labs/lm32
<cr1901_modern>
(provided you have iverilog installed)
<FelixVi>
I think I'll focus on figuring out why I can't get the SDRAM phy to run faster first
<cr1901_modern>
sb0: Could we discuss linking to unofficial lm32-elf-gcc Windows binaries again? And possibly make/chmod too? I don't mind hosting them on my website.
<cr1901_modern>
Compiling a Windows gcc isn't difficult. Just tedious. Users might want to skip that step. You were receptive last time we discussed it.
<FelixVi>
for now, I won't touch lm32
<FelixVi>
but there is an example of ZPU where 4 instructions are decoded and executed every 4 cycles
<cr1901_modern>
FelixVi: Is it possible that the SDRAM bandwidth you have is just shit (I'm being sincere; minispartan has the same issue for doing HDMI)?
<FelixVi>
if you're interested, I can dig that up
<cr1901_modern>
I only use ZPU for ice40hx1k
<cr1901_modern>
So I can claim I can fit a "32 bit CPU" in 1k LUTs :)
<FelixVi>
cr1901_modern: It should be the same as pipistrello which can run at 81.333 MHz
<FelixVi>
hehe
<cr1901_modern>
(Also it's a stack machine, so... bleh)
<FelixVi>
So I'm pretty sure I'm doing something not quite right with the DDR phy
<cr1901_modern>
My sympathies :(
<FelixVi>
well, I thought about putting LOC constraints on the serdes and FFs in the phy to make sure they are in the same place as for pipistrello
<FelixVi>
but the fabric is a bit slower overall
<FelixVi>
I think ultimately I should pop the SDRAM on one of the boards and look at the timing on a scope
<FelixVi>
that way I can at least see what's going on
<cr1901_modern>
Is the sdram BGA?
<FelixVi>
yeah
<cr1901_modern>
Perhaps instead of popping off the board, you can just do a route-through from the I/O headers to the SDRAM?
<cr1901_modern>
(unless the skew matters)
<FelixVi>
That might be a better way. I'm more concerned that it'll change the routing
<FelixVi>
I looked at it in FPGA editor and I think I see why it happens
<FelixVi>
but there isn't any constraints one can easily use beyond period constraints
<cr1901_modern>
You should be able to constrain to a particular CLB
<FelixVi>
so pipistrello is nicely optimized, but saturn isn't because the cpu runs at low speed
<FelixVi>
yeah, LOC does that
<FelixVi>
so I can nail down the FFs before IOBs
<FelixVi>
and that way, the output timing should be the same
<FelixVi>
I think that's a viable solution because the memory IOs are fixed anyways
<FelixVi>
but let me make sure I don't do anything stupid elsewhere
<FelixVi>
Ultimately, though, a fixed location for a memory interface isn't really a bad thing IMO
<cr1901_modern>
How are LOC constraints done in Verilog, attributes?
<cr1901_modern>
(* LOC = "whatever" *)
<FelixVi>
you can put those in the ucf
<cr1901_modern>
Oh, for individual FFs?
<cr1901_modern>
(well, regs anyway)
<FelixVi>
yeah
<cr1901_modern>
Oh didn't know that
<FelixVi>
it's the same LOC constraint you use for pins
<cr1901_modern>
Oh...
<FelixVi>
I haven't tried it yet, but I think that would help
<FelixVi>
It's pretty manual, but should work for all LX45-csg324 and that memory IC (as long as trace length are close to matched)
<FelixVi>
as I use LX45-csg324 for most things, that would make me pretty happy :)
<FelixVi>
oh yeah, and speed grade -2
<FelixVi>
Here, this shows what I am wondering about: